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PREFACE 


This  Techno!og>’  Issues  &  Alternatives  Report  was  prepared  by  the  Transportation  Systems 
Center  (TSC)  of  the  U.S.  Department  of  Transportation  (DOT)  to  document  the  findings 
from  the  Proof  of  Concept  (POC)  work  done  in  FY89  and  the  early  part  of  FY90  on  the  U.S. 
Air  Force  Technical  Order  Management  System  (AFTOMS)  project.  AFTOMS  is  the  first 
major  implementation  resulting  from  the  Air  Force  Computer-aided  Acquisition  and  Logis¬ 
tic  Support  (CALS)  program. 

The  objectives  of  the  POC  work  were: 

•  Further  development  of  the  system  concept  presented  in  the  AFTOMS  Auto¬ 
mation  Plan-Final  Report ,  dated  February’  1988; 

•  Evaluation  of  the  economic  feasibility  of  the  system  concept  (findings  docu¬ 
mented  separately  in  an  FY89-FY30  Feasibility  Study,  dated  December  1989): 
and 

•  Evaluation  of  the  risks  associated  with  the  system  concept,  technologies  re¬ 
quired  to  implement  AFTOMS,  and  identification  of  risk  abatement  strategies. 

The  POC  work  was  performed  under  the  direction  of  the  Information  Integration  Division  at 
TSC.  TSC  has  drawn  upon  the  skills,  Knowledge,  and  professional  work  of  several  organiza¬ 
tions  forming  a  multi-faceted  team  of  experts,  each  of  whom  has  made  a  vital  contribution. 
TSC  would  like  to  extend  its  gratitude  to  the  following  organizations:  EG&G  DYNATREND 
Inc.  and  UNISYS  Inc. 


AFTOMS  POC  risk  assessment  and  abatement  was  performed  using  a  closely  integrated  dual 
approach:  a  hands-on  effort  to  design  and  build  a  Demo  System;  and  a  hands-off  effort  to 
evaluate  and  assess  AFTOMS,  its  technology,  and  integration  needs. 


This  report  is  an  important  document  in  the  definition  phase  of  AFTOMS  preceding  the  sys¬ 
tem’s  Full-Scale  Engineering  Development  (FSED);  the  report  will  influence  the  final  re¬ 
quirements  in  the  Request  for  Proposal  (RFP),  the  source  selection  evaluation  criteria,  and 
the  architectural  design  of  AFTOMS.  Any  constructive  comments  or  inputs  are  welcome  so 
that  this  document  will  be  accurate  and  useful  for  the  program. 


This  document  is  a  typical  product  of  the  technical  documentation  management  system  that 
will  evolve  through  the  implementation  of  AFTOMS.  Although  this  document  does  not  con¬ 
form  to  MIL^STD  1840,  the  Automated  Interchange  of  Technical  Information  (ATTI)  stan¬ 
dard,  or  incorporate  Standard  Generalized  Markup  Language  (SGML)  tags,  it  illustrates  sev¬ 
eral  of  the  system  features  that  will  be  applicable  for  AFTOMS.  These  system  features  in¬ 
clude:  !  '■ " 
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Integration  of  text,  graphics  and  tables; 

Electronic  storage  and  component  configuration  control; 
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•  Revision  capability  and  change  control;  and 

•  Computer-based  printing  on  demand. 

A  300  dpi  laser  printer  was  used  to  print  this  document;  this  printer  resolution  is  the  minimum 
recommended  for  on-request  printing  of  digital  technical  orders  (TOs)  distributed  and  man¬ 
aged  by  AFTOMS. 


EXECUTIVE  SUMMARY 


INTRODUCTION 

This  executive  summary  10  the  AFTOMS  Technology'  Issues  &  Alternatives  Report  is  broken 
down  into  the  following  headings: 

•  CALS  Program  and  TSC’s  Role;  a  historical  introduction  covering  the  FY 
85-FY89  time  frame; 

•  Existing  (As-Is)  TO  System;  an  overview  of  the  current  manually-oriented 
system  and  its  problems; 

•  Automated  (To-Be)  TO  System  Concept;  a  brief  introduction  to  the  future 
automated  AFTOMS; 

•  AFTOMS  Proof  of  Concept  (POC);  an  overview  of  TSC's  FY89-FY90 
work;  and 

•  Key  Conclusions  and  Recommendations. 

CALS  PROGRAM  AND  TSC’S  ROLE 

This  introduction  covers  the  time  period  from  inception  of  the  Computer-aided  Acquisition 
and  Logistic  Support  (CALS)1  Program  in  FY85  through  planning  for  the  FY89  AFTOMS 
POC  work  at  TSC. 

The  CALS  Program  was  established  to  improve  weapon  system  reliability  and  maintainabil¬ 
ity.  and  to  reduce  the  costs  of  weapon  system  acquisition  and  support.  One  major  continuing 
objective  of  the  CALS  Program  is  to  improve  the  delivery  and  handling  of  large  quantities  of 
technical  data.  CALS  will  significantly  reduce  the  amount  of  paper  and  labor  necessary  to 
enter,  manipulate,  transfer,  and  interpret  such  data. 

In  June  1985,  a  joint  industry/DoD  Task  Force  on  CALS  issued  a  five  volume  report  (IDA 
R-285),  which  presented  the  objectives  and  scope  of  the  program,  as  well  as  a  top-level  man¬ 
agement  and  implementation  plan.  On  18  October,  1985,  Program  Management  Directive 
(PMD)  5260(1),  Automation  of  Technical  Information  and  Computer  Aided  Logistics  Sup¬ 
port  (CALS),  established  the  CALS  program  and  chartered  the  Air  Force  CALS  Manage¬ 
ment  Integration  Office  (MIO)  at  Headquarters  (HQ)  Air  Force  Systems  Command  (AFSC) 
to  coordinate  the  CALS  program  within  the  Air  Force.  The  MIO  is  responsible  for  planning, 
developing,  and  implementing  CALS  initiatives. 

Initially,  the  MIO  identified  three  areas  of  technical  information  for  review  and  improve¬ 
ment:  Technical  Order:  (TOs),  Product  Definition  Data  (PDD),  and  Logistics  Support  Analy- 

1.  This  is  the  current  title  of  the  program;  originally,  ’’Acquisition"  was  not  in  the  title,  the  "A"  in  the 
acronym  stood  for  "Aided",  and  Logistic  was  plural. 
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sis  (LSA).  In  1986,  TSC  was  contracted  by  the  AFSC  MIO  to  provide  systems  engineering 
support  to  create  automation  plans  for  these  areas. 

The  initial  TSC  support  consisted  of  review  and  analysis  of  existing  programs  and  standards. 
TSC  developed  a  modular  planning  process,  essentially  an  information  engineering  system 
approach,  to  perform  the  activities  associated  with  automation  planning.  In  1987,  it  implem¬ 
ented  this  planning  process  in  developing  a  7-10  year  automation  plan  for  TOs,  broken  down 
into  *hree  distinct  phases.  These  phases  are  listed  below,  along  with  the  time  frames  in  which 
they  were  conducted  for  TOs: 

•  As-Is.  An  examination  of  the  existing  environment  (March-June,  1987); 

•  To-Be.  A  study  of  opportunities  and  initial  formulation  of  a  system  concept 
for  automation  (May-August,  1987);  and 

•  Automation  Plan.  Consensus  building  within  the  Ar  Force  for  refining  the 
concept,  mobilizing  action  on  it,  and  developing  a  plan  for  future  direction 
(July  1987-February  1988). 

The  AFTOMS  concept  that  evolved  from  the  modular  planning  process  was  a  result  of  com¬ 
bining  TSC  analyses  with  ideas  received  from  the  Ar  Force  and  industry;  this  formed  the  basis 
for  the  TO  automation  plan,  documented  in  DoD-VA  856-88-3,  AFTOMS  Automation  Plan 
-  Final  Report,  dated  February  1988. 

Responsibility  for  AFTOMS  exploration,  definition,  development,  and  deployment  was  as¬ 
signed  in  FY88  to  the  Ar  Force  Logistics  Command  (AFLC);  this  command  established  an 
AFTOMS  System  Program  Office  (SPO),  located  at  Wright-Patterson  Ar  Force  Base 
(WPAFB)  in  Dayton  Ohio,  to  manage  all  necessary  work  to  implement  the  AFTOMS  Auto¬ 
mation  Plan.  For  the  remainder  of  FY88,  TSC  supported  the  SPO  in  briefing  the  AFTOMS 
concept  within  the  Ar  Force  community  and  in  planning  the  POC  work  which  began  inIT789. 

The  purpose  of  the  POC  is  to  investigate  the  AFTOMS  concept  more  deeply  and  systemati¬ 
cally,  identify  and  assess  its  benefits  and  risks,  find  approaches  for  avoiding  or  abating  those 
risks,  and  identify  any  previously  overlooked  opportunities;  these  will  provide  early  technical 
input  to  the  SPO  that  can  be  used  to  leverage  and  enhance  AFTOMS  success.  Such  input  also 
provides  a  basis  for  supporting  RFP  technical  requirements  preparation,  source  selection  cri¬ 
teria  for  evaluating  RFT  responses  from  contractors,  and  various  AFLC  and  DoD  program 
reviews. 

EXISTING  (AS-IS)  TECHNICAL  ORDER  SYSTEM 

The  Ar  Force  established  the  existing  TO  system  in  the  1940s.  This  system  is  the  official 
medium  for  disseminating  technical  orders,  instructions,  and  safety  procedures  for  Ar  Force 
systems  and  equipment.  According  to  AF  Regulation  (AFR)  8-2,  TOs  are  military  orders 
issued  in  the  name  of  the  Chief  of  Staff,  U.S.  Ar  Force  (USAF),  by  order  of  the  Secretary  of 
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the  Air  Force,  and  require  mandatory  compliance.  The  existing  TO  system  is  primarily  a  man¬ 
ual  operation. 

Currently,  there  are  over  150,000  TOs  in  use.  These  TOs  are  managed  by  five  AFLC  Air 
Logistics  Centers  (ALCs)  and  the  Aerospace  Guidance  and  Metrology  Center  (AGMC);  and 
are  segregated  by  specific  weapon  system  or  commodity.  The  average  TO  document  ranges 
from  100-to-150  pages  in  length,  comprising  60%  text  and  40%  graphics.  The  total  TO  in¬ 
ventory  exceeds  20  million  original  pages  of  master  copy  (exclusive  of  working  or  distributed 
copies).  Annual  production  of  change  pages  averages  about  2.3  million  original  pages  a  year. 
In  addition,  the  current  and  growing  backlog  of  unfilled  requirements  is  estimated  to  exceed  2 
million  pages. 

Four  major  USAF  commands  are  involved  in  the  creation,  use,  and  management  of  TOs. 
AFSC  acquires  major  systems,  monitors  product  development  contracts,  and  conducts  test 
and  evaluation  efforts  (including  TO  validation  and  verification)  with  the  assistance  of  using 
and  supporting  commands.  The  major  commands  (MAJCOMs)  that  use  the  system  provide 
functional  requirements,  some  technical  specifications,  and  participate  in  test  and  evaluation 
efforts.  Within  AFLC,  the  ALCs  provide  the  logistics  support,  including  TO  maintenance 
and  distribution  required  for  effective  operation  and  maintenance  of  the  systems.  Air  Train¬ 
ing  Command  (ATC)  provides  a  wide  range  of  training  associated  with  the  operation  and 
maintenance  of  systems,  including  the  use  of  TOs. 

Currently,  all  USAF  TOs  are  created,  inventoried,  and  distributed  as  paper  documents.  Al¬ 
though  many  documents  are  created  and  maintained  by  contractor  systems  in  paper  and  digi¬ 
tal  form  they  are  delivered  to  the  Air  Force  as  paper  copies,  since  the  current  USAF  TO  sys¬ 
tem  is  incapable  of  accepting  digital  delivery.  The  Automated  Technical  Order  System 
(ATOS),  implemented  at  five  ALCs  and  AGMC,  selectively  scans  existing  TO  pages  for  digi¬ 
tal  storage  and  subsequent  editing.  However,  digital  change  management  using  this  tech¬ 
nique  affects  only  a  small  portion  of  the  entire  TO  inventory  and  its  change  processing. 

Maintenance  technicians  who  need  specific  TOs,  send  a  standardized  TO  Request  Form 
(AFTO)  to  a  TO  Distribution  Office  (TODO)  who  then  orders  the  requested  TOs  from  the 
Oklahoma  City  ALC  (OC-ALC)  central  distribution  point.  The  OC-ALC  sends  a  mailing 
label  to  the  appropriate  ALC,  which  mails  the  TO  to  the  TODO.  Revisions  and  supplements 
follow’  a  similar  procedure. 

A  June  1986  report  of  the  HQ  Air  Force  Audit  Agency  (AFAA)  (Audit  #5036410,  Acquisi¬ 
tion  of  Technical  Orders  from  Contractors)  cited  several  deficiencies  in  the  existing  system. 
These  included: 

•  Contractors  frequently  fail  to  provide  installation-level  TOs  in  time  for  Air 
Force  verification; 

•  Up  to  500  days  are  needed  to  fully  implement  a  routine  change  to  a  TO; 


•  Error-prone  desk-top  analysis  and  validation  of  TOs  is  frequently  per¬ 
formed  in  lieu  of  actual  performance  of  tasks; 

•  From  1977  to  1986,  47%  of  Cause  Code  1  (Inadequate  Technical  Data) 
mishaps  listed  inaccurate  TOs  as  a  contributing  factor  with  resulting  equip¬ 
ment  losses  of  about  $86  million;  and 

•  The  Air  Force  does  not  separate  the  cost  of  TO  preparation  from  the  cost  of 
a  weapon  system,  making  cosf  control  difficult. 

In  conclusion,  the  present  paper-oriented  system  is  inefficient  and  is  unable  to  meet  the  grow¬ 
ing  requirements  of  the  USAF  Asingle  modem  weapon  system,  such  as  the  Bl-B,  generates 
approximately  3500  new  TOs,  adding  over  a  million  original  master  pages  to  the  current  TO 
inventory'.  This  additional  volume  cannot  be  managed  by  the  present  system  in  a  timely  fash¬ 
ion.  All  these  facts  brought  about  the  formulation  of  a  practical  automation  plan  that  would 
lead  to  a  more  efficient  and  powerful  TO  system;  AFTOMS,  capable  of  meeting  the  present 
needs  and  the  future  requirements  of  the  USAF. 

AUTOMATED  (TO-BE)  TECHNICAL  ORDER  SYSTEM  CONCEPT 

As  discussed  in  Appendix  A,  the  To-Be  system  concept  was  developed  during  the  automation 
planning  phase  and  refined  with  supporting  detail  early  in  FY89  as  part  of  the  POC.  Essen¬ 
tially,  the  current  To-Be  model  views,  analyzes,  and  characterizes  AFTOMS  from  six  impor¬ 
tant  perspectives: 

•  Operational  environment; 

•  System  functionality'; 

•  User  interfaces  and  system  usability; 

•  System  capacities  and  performance; 

•  Technologies  needed  to  build  the  system;  and 

•  System  implementation  issues. 

The  AFTOMS  To-Be  system  requires  acquisition  of  new  TOs  in  digital  form  only,  provides 
for  paper-to-digital  scanning  conversion  of  the  existing  TO  inventory,  and  manages  a  mixed 
inventory  of  TOs  (including  paper  TOs).  Since  AFTOMS  functionality  is  fully  and  most  pro¬ 
ductively  usable  only  on  digital  TOs  the  automation  benefits  increase  proportionately  as  the 
total  TO  inventory  moves  closer  to  total  digitization.  A  digital  TO  can  simply  be  a  computer- 
based  display  of  a  paper  document,  where  individual  pages  are  called  up  for  screen  viewing  or 
printing.  More  useful  possibilities  include  automated  interconnection  of  related  material  and 
tailored  content  presentation  based  on  technician  experience  level,  maintenance  task,  air¬ 
craft  tail  number,  etc.  An  even  more  advanced  concept  (e.g.  Type  C)  would  link  individual  TO 
data  elements  under  the  control  of  a  database  manager,  which  allows  the  maintenance  techni¬ 
cian  to  assemble  related  TO  information  on  the  screen  interactively,  as  tasks  require. 


-VI- 


d 


In  developing  a  To-Be  system  concept  to  manage  the  acquisition  and  distribution  of  digital 
TOs,  consideration  was  given  to  a  modular  functional  framework  that  easily  maps  to  the  exist¬ 
ing  Air  Force  infrastructure.  Modularity  allows  phased  weapon  system-based  implementa¬ 
tion  (across  ALCs  and  Air  Force  bases)  at  a  pace  consistent  with  A'r  Force  requirements  and 
appropriations.  To  meet  the  objectives  of  more  accurate,  complete,  timely  and  cost  effective 
TOs.  the  To-Be  establishes  cletrly  defined  responsibilities  and  logical  information  flows. 

AFTOViS  consists  of  four  tiers  whose  elements  are  distributed  in  functional  and  organiza¬ 
tional  location.  The  four  tiers  are  hierarchical  with  centralized  TO  control  from  the  top  down. 
At  the  top.  Tier  1  is  a  single  organization/facility  within  the  Air  Force,  called  the  Air  Force 
Technical  Order  Management  Administration  (AFTOMA),  responsible  for  the  demonstra¬ 
tion.  implementation,  and  management  of  the  entire  automated  TO  system.  Tier  2  is  an  ex¬ 
panding  network  of  multiple  TO  Management  Agencies  (TOMAs);  Tier  3  consists  of  Consol¬ 
idated  TO  Distribution  Offices  (CTODOs)  at  base  level;  and  Tier  4  has  Work  Areas  (WAs). 
AFLC  will  staff  Tiers  1  and  2,  whereas  the  MAJCOMs  will  staff  Tiers  3  and  4. 

TOM  A  TO  Centers  (TOCs)  are  subfacilities  of  an  ALC.  Each  TOM  A*TOC  is  responsible  for 
the  management  (i.e.  acquisition,  planning,  development,  distribution,  and  updating)  of  the 
complete  suite  of  TOs  for  a  single  weapon  system.  It  must  be  emphasized  that  the  TOC's 
responsibility  for  the  complete  suite  of  weapon  system  TOs  is  a  major  departure  from  the 
existing  organization.  Currently.  TOs  for  a  weapon  system  are  the  responsibility  of  several 
ALCs,  each  with  a  different  subsystem  specialty.  In  the  To-Be  concept,  the  TOMATOC 
needs  to  acquire  and  distribute  all  TOs  for  a  specified  weapon  system  regardless  of  the  TO 
source  organization.  Each  weapon  system  will  then  be  supported  by  a  single  TOC.  This  TOC 
retains  all  types  of  TOs  in  one  location  to  control  and  improve  TO  management  for  that 
weapon  system. 

Since  weapon  systems  share  many  common  equipment  items,  such  as  engines  and  avionics,  a 
need  exists  to  create  TOCs  specializing  in  these  commodities.  Commodity  TOCs  will  elimi¬ 
nate  the  duplication  of  effort  that  would  occur  if  each  weapon  system  TOC  managed  its  own 
commodity'  TO  inventory.  Commodity  TOCs  will  ,ot  distribute  directly  to  the  Air  Force 
bases  but  only  to  weapon  system  TOCs  requiring  that  commodity  TO.  The  weapon  system 
TOC  will  then  place  these  TOs  into  its  suite  for  bulk  distribution  (using  optical  disk  media)  to 
base-level  CTODOs.  AH  other  functions  (acquisition,  management,  production,  etc.)  for 
commodity  TOs  remain  the  responsibility  of  the  commodity  TOC.  In  addition  to  weapon 
system  and  commodity  TOCs,  there  will  be  TOCs  to  support  non-weapon  system  related  TOs 
for  such  items  as  support  vehicles,  policy  and  procedures,  indices,  etc.  The  AFTOMA  will 
have  a  non-weapon  system  TOC  to  support  its  administrative  TO  requirements.  Therefore, 
an  ALC  will  house  a  mix  of  TOMA/TOCs  each  with  its  own  TO  responsibilities. 

In  the  AFTOMS  infrastructure,  each  of  the  top  three  tiers  contains  data  center  facilities  de¬ 
signed  to  provide  centralized  and  distributed  computer  services/resources  at  each  physical 
location  for  tier  level  organizational  processing,  communications,  production  and  distribu- 
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tion.  At  the  AFTOMA  and  TOMAs,  these  facilities  are  relatively  extensive,  providing  com¬ 
puters,  storage  capabilities  and  printers  networked  via  local-area  communications.  Each 
TOC  has  its  own  interconnected  workstations  that  are  networked  to  the  ALC.  Since  CTO- 
DOs  will  support  base  -level  requirements,  the  configuration  of  their  data  center  will  match 
required  capacities.  All  CTODOs  will  need  to  provide  administrative  processing.  TO  stor¬ 
age.  high  speed  printing,  and  communication  to  the  AFTOMA  Configurations  will  range 
from  Local  Area  Network  (LAN)-based  workstation  computer  systems  to  minicomputer  sys¬ 
tems,  file  servers,  and  high-speed  laser  printers. 

Top-down  data  flow  through  the  four  tiers  of  AFTOMS  is  controlled  by  the  AFTOMA  and 
the  associated  hierarchy.  The  AFTOMA  maintains  a  list  of  all  active  TOMA/TOCs  and  their 
associated  weapon  systems  responsibilities.  Therefore,  the  AFTOMAis  ideally  positioned  to 
be  the  control  point  for  TO  distribution  and  authorization.  When  TO  requests  are  registered 
by  Work  Area  users  in  Tier  4,  information  flows  up  to  the  AFTOMA  at  Tier  1  and  the  re¬ 
sponse  flows  down  through  the  tiers  until  it  returns  to  Tier  4.  This  arrangement  provides  cen¬ 
tralized  control  and  distribution  management. 

Work  .Areas  request  technical  information  in  the  form  of  task  definition  profiles  from  the 
C  TODOs.  which  then  send  the  request  to  AFTOMA  The  AFTOMA  either  responds  to  a 
request  directly  or  distributes  the  request  to  a  specific  TOC  (Tier  2).  TOCs  may  then  pass 
r  .-quested  data  (usually  TOs)  back  to  the  CTODO  for  distribution  to  the  Work  Area.  It  is 
important  to  note  that,  in  this  top-down  flow  strategy,  CTODOs  do  not  request  information 
directly  from  TOCs.  Therefore,  the  CTODO  need  not  knowthe  location  of  TOs.  This  simpli¬ 
fies  the  ordering  process,  communications  paths,  and  allows  the  AFTOMA  flexibility  in  as¬ 
signing  TOC  responsibilities. 


In  establishing  the  functional  requirements  of  the  AFTOMS  system,  an  infrastructure  was 
designed  to  serve  the  management  and  distribution  of  TOs  regardless  of  their  type.  All  TO 
types  need  a  system  that  can  provide  the  core  activities  of  acquiring,  archiving,  cataloging, 
distributing,  and  updating  (change  management). 


In  summary,  this  AFTOMS  To-Be  concept  supports  an  implementation  strategy  that  in¬ 
volves: 


•  Capturing  Type2  A  (paper)  TOs  u.ring  scanners; 

•  Using  Type  B  (page-oriented,  digital)  TOs  in  the  shot*  term; 

•  Supporting  Type  C  (pageless,  digital)  TOs  for  newer  weapon  systems  when 
this  technology  becomes  available  (AFTOMS  operational  support  require¬ 
ments  for  Type  C  still  need  to  be  investigated  in  detail; 

•  Using  new  technology  for  scanning,  cataloging,  storing,  and  retrieving  in¬ 
formation; 


2.  The  various  types  of  TOs,  their  characteristics,  as  well  as  the  AFTOMS  infrastructure  components  are 
described  more  fully  in  the  Key  Terms  section  of  this  report,  which  precedes  the  List  of  Acronyms. 
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•  Distributing  TOs  to  CTODOs  and  automated  Work  Areas  via  optical  disk 
media: 

•  Supporting  sophisticated  entry,  modification,  and  on-line  retrieval  capa¬ 
bilities; 

•  Supporting  efficient  document  management; 

•  Distributing  information  based  on  specific  profiles  of  Work  Area  user 
groups 

•  Storing  all  types  of  information  (textual,  graphical,  tabular,  etc.)  in  a  unified 
manner; 

•  Preparing  TOs  concurrently  during  the  development  of  weapons  systems 
with  interactive  review  of  TOs  in  progress;  and 

•  Establishing  streamlined  organizational  and  operating  procedures. 

The  AFTOMS  approach  will  lead  to  many  long-term  benefits  for  the  Air  Force  including 
increased  weapon  system  availability7,  reduced  costs,  and  increased  mission  effectiveness. 
AFTOMf  provides  the  flexibility7  needed  to  support  the  more  sophisticated  weapon  systems 
of  the  future. 

AFTOMS  PROOF  OF  CONCEPT  (POC) 

The  purpose  of  the  POC  is  to  investigate  the  AFTOMS  concept  more  closely  and  systemati¬ 
cally,  identify  and  assess  its  benefits  and  risks,  find  approaches  for  avoiding  or  abating  those 
technical  risks,  and  identify  any  previously  overlooked  opportunities,  thus  providing  early 
technical  input  to  the  SPO  that  can  be  used  to  leverage  and  enhance  AFTOMS  success. 

TSC’s  POC  Strategy 

The  POC  strategy  has  three  major  and  interacting  activities,  each  of  which  has  its  own  signifi¬ 
cant  characteristics  and  deliverables: 

•  Prototyping  a  Demo  System; 

•  i.va!uating  technologies  and  identifying  risk  abatement  strategies;  and 

•  Performing  a  Feasibility  Study. 

The  Demo  System  focuses  on  understanding  and  implementing  key  aspects  of  the  To-Be  con¬ 
cept  functionality,  using  technologies  and  products  that  are  suitable  for  AFTOMS.  In  the 
process,  a  great  deal  of  invaluable  hands-on  experience  is  gained  in  working  with  current  ana 
emerging  state-of-the-art  technologies,  integrating  technology  products  with  critical  Ai  - 
TOMS  functionality,  finding  and  evaluating  technological  and  operational  problem  areas, 
and  developing  a  visible  and  dynamic  basis  for  refining  AFTOMS  requirements.  The  deliver- 
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able  is  a  packaged  Demo  System  to  be  installed  at  the  AFTOMS  SPO,  which  could  then  be 
used  to: 

•  Provide  a  model  for  refining  RFP  requirements  and  source  selection  crite¬ 
ria; 

•  Provide  a  system  capability  that  can  be  enhanced  to  assess  and  develop  criti¬ 
cal  technical  issues  (e.g.,  data  conversion,  data  loading.  Tier  4  interfaces, 
CALS  standards,  organizational  infrastructure  issues,  etc.); 

•  Serve  as  a  low-cost  test  bed  (before  and  during  AFTOMS  FSED)  for  inde¬ 
pendently  evaluating  problems  and  alternative  solutions,  without  disrupt¬ 
ing  the  main  AFTOMS  development  effort; 

•  Provide  a  training  vehicle  for  prime  contractor  developers  and  TV  &  V  con¬ 
tractor  evaluators;  and 

•  Demonstrate  AFTOMS  to  managers  and  users  from  USAF,  DoD,  and  in¬ 
dustry. 

The  technology  evaluation  activity  consists  of  a  primary  hands-off  path  that  is  supported  by 
limited  hands-on  evaluations  of  selected  technologies  and/or  products  not  incorporated  into 
the  Demo  System.  The  primary'  path's  evaluation  focus  is  quite  broad,  including  investigation 
of  To-Be  requirements,  integration  issues,  advanced  technologies,  standards,  system  build- 
ability  and  operational  utility'  issues,  as  well  as  interoperability  with  other  Air  Force  systems. 
This  broad,  systematic  approach  makes  its  findings  particularly  suitable  for  input  into  the 
RFP  and  source  selection  work  being  performed  by  the  AFTOMS  SPO,  but  its  findings  are 
also  valuable  to  the  AFTOMS  prime  and  TV  &  V contractors.  The  deliverable  for  this  activity 
is  the  Technology  Issues  &  Alternatives  Report.  It  should  be  noted  that  significant  and  relevant 
functionality  and  technology  findings  from  the  other  POC  activities  (prototyping  a  Demo  Sys¬ 
tem  and  the  Feasibility  Study)  are  also  integrated  into  this  report. 

The  Feasibility  Study  activity',  performed  by  TSC,  focuses  both  on  the  As-Is  environment  and 
the  To-Be  concept  to  perform  an  operational  and  economic  feasibility  assessment  of  AF¬ 
TOMS.  The  deliverable  is  the  Feasibility  Study  Report,  which  is  used  by  the  SPO  to  develop 
and  justify  the  AFTOMS  program  funding. 

An  adequately  detailed  To-Be  model  drives,  focuses,  and  integrates  these  three  activities 
(prototyping  a  Demo  System,  technology  evaluation,  and  feasibility  study).  An  initial,  high- 
level  To-Be  system  concept  for  AFTOMS  was  developed  for  the  Automation  Plan.  However, 
more  detail  was  required  for  the  concept  to  be  useful  as  a  basis  for  either  the  POC  work  or  the 
development  of  RFP  requirements,  and  as  a  common,  integrated,  coordinated,  and  approved 
concept.  The  resulting  To-Be  Model  (Appendix  A  in  the  Supplement)  was  coordinated  within 
the  AFTOMS  community. 


Risk  Abatement  Methodology 

The  core  focus  of  AFTOMS  POC  methodology  is  risk  abatement.  Fundamentally,  this  is 
achieved  by  developing  a  thorough  project  understanding  using  a  balanced  combination  of 
the  following  techniques: 

•  Through  hands-off  methods  requiring  detailed  analysis: 

o  Exploring  the  To-Be  concept  analytically  and  systematically  to 
probe  for  logical  needs,  problems,  and  consequences;  and 

•  Through  hands-on  Demo  System  or  technology  evaluation  work: 

o  Prototyping  to  test  and  verify  the  analysis,  evaluate  technologies  and 
products  relative  to  the  specific  needs  of  AFTOMS,  and  to  investi¬ 
gate  technical  integration  problems. 

The  value  of  obtaining  such  a  thorough  project  understanding  before  defining  and  building 
the  real  system  is  practical  and  significant.  It  anticipates  opportunities  and  resolves  problems 
that  could  appear  later,  thereby  reducing  the  total  burden  during  FSED;  and  it  provides  a 
coherent,  integrated,  and  AFTOMS -specific  framework  for  quicker  evaluation  and  resolu¬ 
tion  of  problems  and  exploitation  of  opportunities  that  may  arise  in  the  future.  The  benefits 
of  this  framework  involve  the  reduction  of  project  risk  by  reducing: 

•  Surprises  and  unintended  consequences  downstream; 

•  Changes  and  iterations  during  development; 

•  Schedule  slippages; 

•  Compromises  in  delivered  functionality,  performance,  and  system  quality. 

•  Follow-on  Engineering  Change  Proposals  (ECPs)  to  fund  after  project 
completion;  and  by 

•  Providing  a  means  to  prototype  high-risk  options  in  a  limited  environment 
without  burdening  and  jeopardizing  the  full-scale  effort  with  avoidable 
problems. 

This  framework  can  also  be  used  to  train  system  developers,  IV  &  V  personnel,  etc.,  to  more 
quickly  understand  the  AFTOMS  requirements  and  technologies,  thereby  shortening  their 
learning  curves  and  providing  a  partial  substitute  for  any  lack  of  AFTOMS-relevant  experi¬ 
ence. 

Prior  to  the  start  of  the  POC  effort,  the  prevailing  perception  within  the  AFTOMS  community 
was  that  reliance  on  state-of-the-art  and  emerging  technologies  posed  the  greatest  risks  to 
project  success.  However,  the  early  part  of  the  POC  effort  focused  on  refining  the  To-Be 
concept  and  evaluating  numerous  candidate  technology  products;  and,  it  became  apparent 
that  there  were  more  significant  risks  present  in  various  integration  dimensions.  Therefore, 
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the  POC  scope  was  amended  to  incorporate  eight  additional  risk  evaluations  of  integration 
issues  in  addition  to  the  sixteen  technology  risk  evaluations,  thereby  providing  a  more  com¬ 
plete  and  thorough  report  (see  Section  2.1  for  the  eight  integration  risk  evaluations  and  Sec¬ 
tion  3.1  for  the  sixteen  technology  risk  evaluations). 

The  FY89-FY90  POC  methodology  focuses  on  AFTOMS;  its  operating  environment,  impor¬ 
tant  risk  issues  within  two  time  frames:  FY89  to  develop  a  current  assessment  of  technologies, 
products,  integration  problems,  and  other  risks;  and  FY91-FY93  to  project  future  asses¬ 
sments  of  these  technology  products,  problems,  and  risks  to  the  time  frame  when  the 
full-scale  AFTOMS  system  will  be  designed  and  built.  Given  its  time  and  resource  limita¬ 
tions.  the  POC  approach  is  disciplined  to  focus  on  important  issues  of  consequence  to  AF¬ 
TOMS.  It  is  a  multi-dimensional  approach  that  incorporates  users,  work  procedures,  opera¬ 
tional  constraints,  technologies,  and  interfacing  issues.  It  is  also  an  integrated  approach, 
making  use  of  the  comparative  advantages  of  various  techniques  to  explore  different  aspects 
of  issues,  then  balancing  and  combining  those  investigations  and  results  to  get  overall  cover¬ 
age  and  synergy.  Finally,  it  is  an  action-oriented  methodology,  designed  to  make  its  findings 
clear  and  easy  to  refine/update  throughout  the  project  life  cycle. 

Technology  Issues  &  Alternatives  Report 

Based  on  the  work  in  designing  and  building  the  Demo  System,  conducting  other  hands-on 
technology  evaluations,  and  completing  the  hands-off  analytical  approach  demanded  by 
POC,  the  Technology-  Issues  &  Alternatives  Report  documents  the  results  of  the  following  POC 
findings: 

•  Important  AFTOMS  requirements,  risks,  and  opportunities; 

•  Technology  and  integration  lessons  learned;  and 

•  Risk  abatement  recommendations. 

The  report  structure  is  defined  in  Section  1.3.1. 

KEY  CONCLUSIONS  AND  RECOMMENDATIONS 

Since  the  scope  of  the  POC  did  not  include  evaluation  of  Air  Force  organizational  issues,  the 
risks  associated  with  integrating  AFTOMS  into  the  Air  Force  culture  were  not  evaluated. 
However,  technologies  for  developing  a  high-quality,  user-friendly,  and  easy-to-leam  sys¬ 
tem  were  investigated,  thereby  indirectly  reducing  existing  organizational  risks.  The  follow¬ 
ing  findings  from  the  FY89-FY90  AFTOMS  POC  work  that  apply  to  the  AFTOMS  F^SED 
(FY9 1  — FrV93)  are  extracted  from  the  detailed  evaluations  in  Section  2  and  Section  3.  They 
are  organized  into  Major  Conclusions  and  Other  Conclusions  (of  a  less  critical  nature). 

MAJOR  CONCLUSIONS 

•  No  single  Commercial  Off-the-Shelf  (COTS)  product  or  turnkey  inte¬ 
grated  system  will  be  available  to  satisfy  AFTOMS  requirements.  Giver 
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the  uniqueness  of  the  requirements  and  the  needed  technology  mix,  specific 
capabilities  of  commercial  products  used  selectively,  and  the  customized 
software  written  to  unify  purchased  COTS  technology  products  into  one 
seamless  AFTOMS  system,  the  integration  risk  could  actually  exceed  the 
total  technological  risk  associated  with  particular  products.  However,  this 
integration  risk  is  still  significantly  smaller  than  that  which  would  result  if 
AFTOMS  did  not  rely  on  commercial  technology  products,  and  instead  at¬ 
tempted  a  totally  customized  solution  approach. 

The  AFTOMS  To-Be  concept  is  operationally  sound  and  can  be  built  by 
integrating  available  or  emerging  technology  products.  There  are  residual 
risks  associated  with  scanning  conversion,  defining  a  standardized  CTO- 
DO-to-WA  delivery’  interface  to  support  heterogeneous  WA  delivery  sys¬ 
tems,  and  localized  technical  and  scheduling  problems.  However,  these  lo¬ 
calized  problems  should  be  manageable. 

The  AFTOMS  To-Be  concept  is  sufficiently  robust  to  manage  a  mixed  pa¬ 
per  and  digital  TO  inventory,  consisting  of  all  types  of  paper  and  digital 
TOs. 

MIL-STD  1840  must  be  completed  soon  since  timely  development  of  an 
adequate  set  of  consistent  DTDs  and  OSs  (to  cover  the  range  of  new  and 
existing  TOs)  is  critical  to  AFTOMS  success  for: 

o  Scanning  conversion  of  existing  inventory’  of  paper  TOs  (which,  be¬ 
cause  of  inconsistent  standards  historically  have  varying  formats  and 
styles); 

o  Supporting  MIL-STD  1 840  compliant  delivery  of  new  digital  T  Os;  and 
o  Type  B+  tagging  for  value-added  delivery  of  TOs  to  Work  Areas. 
Scanning  conversion  of  existing  weapon  system  TO  suites  is  important  to 
load  the  digital  database  for  AFTOMS.  Otherwise,  the  automation  benefits 
will  fall  short  of  the  projections.  An  early  start  with  a  pilot  operation  is  rec¬ 
ommended  to  develop  a  good  basis  for  planning  and  executing  later  conver¬ 
sions  for  each  new  TOMA  before  it  becomes  operational. 

Type  B+  TOs  provide  a  major  enhancement  to  the  original  AFTOMS  To- 
Be  concept.  Additional  SGML  tagging  of  newly  authored  or  converted  dig 
ital  TO  contents  at  the  TOMA/TOC  level  can: 

o  Mark  text  content  by  security  level,  technician  skill  level,  aircraft  tail 
number,  etc.; 

o  Interconnect  related  text  references  with  referenced  graphics, 
tables,  or  external  TOs;  and 
o  Establish  other  suitable  relationships. 


Such  tagging  provides  more  usable  TOs  at  Work  Areas  by  displaying  only  the 
information  needed  for  the  maintenance  task  (free  of  extraneous  details)  and 
facilitating  rapid,  accurate  retrieval  of  referenced  or  related  technical  data. 
Type  B  +  provides  the  Type  C  benefit  of  tailored  views  at  Work  Areas  without 
the  need  for  additional  sophisticated  AFTOMS  software.  From  a  Type  B  base¬ 
line,  B+  tagging  can  be  implemented  gradually  and  incrementally.  With  Type 
B  + ,  for  example,  additional  tags  can  be  introduced  to  supply  new  capabilities, 
or  old  ones  removed  to  reduce  tagging  cost  or  if  there  are  DTD/OS  defi¬ 
ciencies. 

•  The  existing  inventory  of  paper  TOs  is  extensive;  up  to  50%  can  be  con¬ 
verted  economically  to  Type  B  digital  form.  Weapon  systems  will  acquire 
new  TOs  in  digital  form,  primarily  B  or  B+.  Some  new  weapon  systems 
(e.g.  ATF)  plan  to  acquire  Type  C  TOs.  as  well  as  rely  on  a  substantial  num¬ 
ber  of  existing.  non-Type  C  commodity  TOs.  Conversion  of  such  commod¬ 
ity  TOs  to  Type  C  format  would  be  costly  because  it  would  require  a  yet 
undefined,  re-authoring  approach.  Prior  to  FY2000,  Type  C  TOs  will  com¬ 
prise  a  very'  small  percentage  of  the  Air  Force  TO  inventory.  With  this  in 
mind,  there  are  several  findings  and  recommendations: 

o  AFTOMS  must  and  will  support  Type  C  TOs  when  future  weapon 
systems  require  TO  management  support,  but  initially,  AFTOMS 
should  focus  on  conversion  and  Type  B  support;  and 

o  A  preliminary  high-level  POC  assessment  of  providing  Type  C  sup¬ 
port  shows  that  AFTOMS  needs  to  develop  additional  sophisticated 
software  systems.  These  systems  require  trained  personnel  to  con¬ 
currently  support  two  (Types  B  and  C)  significantly  different  ap¬ 
proaches  to:  TO  authoring;  change  implementation;  verification  of 
the  database  indexing  infrastructure  and  all  allowable  Work  Area 
view's  into  the  TO  database;  and  delivery  of  these  views  from  CTO- 
DOs  to  Work  Areas.  Work  Area  user  access  into  the  Type  C  neuttal 
TO  database  would  have  to  be  restricted  to  formally  verified 
predefined  views. 

•  Technology  will  not  support  an  AFTOMS  solution  that  can  handle  both 
classified  and  unclassified  TOs  in  a  fully  integrated,  secure,  and  trustworthy 
fashion;  therefore,  a  physically  secured,  separate  (but  functionally  identi¬ 
cal)  mini-AFTOMS  is  recommended  for  handling  classified  TOs. 

•  Key  undecided  operational  requirements  for  system  usage  (e.g.,  change 
management  at  Tier  2,  TO  information  traversal  at  Tier  4)  affect  the  design 
of  AFTOMS  in  broad  and  fundamental  ways  and  need  early  resolution. 
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•  A  standard  AFTOMS  interface  between  CTODO  and  Work  Area  delivery 
systems  should  be  defined  so  that  IMIS,  ITDS,  and  other  future  M  AJCOM 
systems  can  easily  interface  to  AFTOMS. 

OTHER  CONCLUSIONS 

•  Graphical  user  interfaces  developed  in  the  Demo  System  appear  to  satisfy 
in  “look  and  feel”  the  needs  of  all  major  user  types  across  the  four  tiers;  and 
are  a  major  contributor  to  the  seamless  integration  of  AFTOMS;  these 
benefits  more  than  offset  their  additional  development  complexity  and 
cost. 

•  Installation  of  AFTOMS  must  be  coordinated  with  various  Offices  of  Pri¬ 
mary  Responsibility  (OPRs).  For  example,  AFCC  is  the  OPR  for  DDN  sup¬ 
port;  on  average,  it  takes  at  least  24  months  from  identification  of  a  require¬ 
ment  for  AFCC  to  install  a  DDN  communications  node. 

•  AFTOMS  buildability  risk  can  be  lowered  significantly  with  a  quality  set  of 
technical  and  operational  requirements  in  the  RFP  that  suitably  constrain 
any  contractor’s  solution  flexibility  and  provide  an  unambiguous  basis  for 
determining  if  a  proposed  and  implemented  solution  meets  AFTOMS, 
MAJCOM,  and  CALS  long-term  needs. 

•  Good  operational  utility'  can  be  built  into  AFTOMS  to  support  its  post-ins¬ 
tallation  use  and  long-term  upgradability,  maintainability,  and  interoper¬ 
ability  '. 

•  Several  key  emerging  technologies  are  evolving  rapidly  and  should  be  mon¬ 
itored  closely';  DMS,  Distributed  RDBMS,  ODS,  and  UIMS. 

•  TO  distribution  from  TOMA  to  CTODO  depends  on  bulk  optical  disks;  the 
lack  of  standards  increases  the  long-term  economic  risk  of  both  optical 
reader  assets  obsolescence  and  spare  parts  availability  when  the  technology' 
changes.  However,  any  necessary  data  conversions  necessitated  by  new' 
standards  could  be  automated  easily. 

•  Several  incompatibilities  exist  between  standards  that  may  not  be  resolved 
and  will  require  workarounds  (e.g.,  optical  disk  media  is  not  yet  accepted  by 
the  government  as  trustworthy  for  archival  storage  of  permanent  records, 
C  +  +  is  not  yet  on  the  DoD  list  of  approved  higher-order  languages,  and 
ADA  [Programming  Language,  MIL-STD  1815]  has  not  been  ported  to  an 
X- Windows  environment,  etc.). 
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•  A  few  technologies  were  found  to  be  inappropriate  for  use  on  AFTOMS 
before  FY2000,  either  because  they  were  too  risky  operationally,  immature 
for  interfacing  with  other  needed  technologies,  or  not  the  best  direct  ap¬ 
proach  to  providing  the  needed  capabilities  accurately  and  predictably 
(e.g.  OODM  and  .Artificial  Intelligence  (AI));  however,  AI  may  still  be  use¬ 
ful  in  providing  localized  capabilities  (e.g.,  TO  numbering  based  on  content 
characteristics). 
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KEY  TERMS 


GENERAL  TERMS 

Proof-of-Concept  (POC)  -  An  activity,  commissioned  by  the  AFTOMS  SPO,  to 

perform  risk  abatement.  It  includes  a  feasibility  study 
activity,  a  technology  assessment  activity,  and  the 
development  of  an  interactive  demonstration  system. 

Demo  System  -  The  interactive  demonstration  system  portion  of  the 

POC  activity.  The  Demo  System  is  a  conceptual  view  of 
the  major  functionality  of  the  AFTOMS  system.  It  is 
composed  of  a  representative  set  of  hardware  and 
software  components,  configured  in  a  mini-version  of 
the  full-scale  AFTOMS  organization  infrastructure, 
designed  to  demonstrate  the  major  functional  activities 
of  the  AFTOMS  system  and  user  interactions. 

Weapon  System  TO  Suite  -  The  entire  set  of  TOs  required  to  fully  operate  and 

support  a  major  weapon  system  (i.e.,  F-15,  B-1B,  C-17, 
ATF,  etc.);  in  addition  to  system-specific  TOs,  this  suite 
includes  all  commodity  TOs  needed  by  the  weapon  sys¬ 
tem. 

Commodity  TOs  -  TOs  which  describe  common  items  that  are  used  in  mul¬ 

tiple  weapon  systems. 

User  Delivery  -  A  system  that  would  be  used  in  Work  Areas  to  receive 

(or  Presentation)  System  technical  information  from  AFTOMS  and  present  this 

information  to  end  users. 


ORGANIZATIONAL  INFRASTRUCTURE  TERMS 


AFTOMA 

(Air  Force  Technical  Order 
Management  Administration) 


Within  the  overall  concept  of  a  modernized  Air  Force 
TO  infrastructure,  the  AFTOMA  will  provide  the 
overall  authority  for  all  procedures  and  policies  involved 
in  administering  the  TO  system.  The  AFTOMA  is 
currently  HQ  AFLC/MM. 


TOMA 

(Technical  Order 
Management  Agency) 


Major  centers  within  the  Air  Force  that  are  responsible 
for  acquiring,  planning,  developing,  and  maintaining 
TOs.  Although  specific  weapon  system-related  TO 
duties  are  delegated  to  the  MM_Rs,  SPOs,  and 
contractors,  each  TOMA  provides  the  overall  manage- 


TOC 

(Technical  Order  Center) 


MM.R 

(Materiel  Management 
Organization) 

CTODO 

(Consolidated  Technical 
Order  Distribution  Office) 


WA 

(Work  Area) 

FUNCTIONAL  TERMS 

Profile  Registration 


ment,  facilities,  and  computer  resources  for  all  TO 
functions.  Currently,  it  is  envisioned  that  the  following 
13  sites  will  be  TOMAs:  five  ALCs  (OO-ALC, 
OC-ALC,  SA-ALC,  SM-A1X,  WR-ALC),  five  AFSC 
SPOs  (ASD,  BSD,  ESD,  MSD,  SSD),  AGMC,  AFCC, 
and  SPACECOM. 

The  TOC  is  a  logical  sub-element  of  the  TOMA;  and  is 
the  focal  point  for  management  of  a  specific  suite  of 
TOs  (i.e.,  F-15,  B-1B,  C-17,  ATF,  etc.).  During 
development  of  a  system,  the  operation  of  a  TOC  is  the 
contractor’s  responsibility  while  overall  management  is 
accomplished  at  the  Air  Force  program  office.  After  the 
TOs  are  formalized,  TOC  operations  move  with  the  TOs 
to  the  Air  Force  supporting  command  (usually  an  AFLC 
prime  center). 

MM_R  is  the  AFLC  Engineering  and  Reliability  sub¬ 
organization  element  of  MM  that  is  responsible  for 
making  content  changes  to  TOs. 

The  CTODO  is  an  AFTOMS  component  installed  at 
each  Air  Force  major  installation  as  the  single-point 
interface  between  AFTOMS  and  all  the  users  of  TOs  and 
TO-related  management  information.  The  CTODO 
will  provide  the  node  at  which  users  of  paper  TOs. 
digital  TOs,  and  interactive  (paperless)  TOs  will: 

(1)  requisition  TOs;  (2)  obtain  TO  management 
information;  (3)  obtain  digital  TOs,  changes, 
supplements,  TCTOs,  etc.,  for  local  printing  and/or 
distribution  to  automated  workstations;  (4)  prepare  and 
submit  automated  TO  publication  change  requests 
(PCRs);  (5)  review  PCRs  at  the  MAJCOM  and  prime 
AFLC:  and  (6)  receive,  store,  and  distribute  interactive 
TOs  to  workstations  throughout  the  base. 

A  generic  term  that  stands  for  any  shop,  office, 
maintenance  station,  work  group,  etc.,  at  an  Air  Force 
installation  that  uses  TOs. 


The  functional  process  by  which  Work  Areas  will  order 
TOs.  Each  work  area  will  specify  its  group 
characteristics  and  requirements;  and  AFTOMS  will 
deliver  the  appropriate  sub-suites  of  TOs  based  on  this 
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group  profile.  Ordering  of  individual  TOs  will  be 
replaced  by  this  simplified  process. 

Cataloging  -  The  functional  process  by  which  TOs  entering  the  system 

are  described  in  key  fields  of  information  in  the 
database.  This  identifying  mfoi  .nation  assists  the  TO 
managers  in  effectively  managing  all  other  AFTOMS 
functions. 

Distribution  -  The  functional  process  of  delivering  TOs  to  their 

ultimate  destinations  (i.e..  Work  Areas). 

On-line  Deliver}'  -  The  functional  process  which  makes  TOs  available  in 

digital  form  for  interactive  access  by  the  users. 

Change  Management  -  The  functional  process  that  encompasses  all  steps 

required  to  change  a  TO.  It  includes  filing  a  change 
request,  reviewing  and  approving  the  change  request, 
authorizing  a  change,  and  making  the  change  to  a  TO. 

Conversion  -  The  functional  process  of  converting  paper  FOs  to 

digital  form  or  of  converting  from  one  digital  form  to  the 
digital  standard;  the  current  digital  standard  is 
MIL-STD-1840. 

TECHNICAL  ORDER  TtTES 

Type  A  -  Characterizes  all  TOs  that  currently  exist  in  the  Air 

Force  inventory  or  will  be  delivered  in  paper  form. 

Type  B-  Characterize*  page-oriented  TOs  in  digital  image  form 

(text  and  graphics  are  in  raster  form). 

Type  B  -  Characterize*  page-orienfed  TOs  in  digital  form. 

TypeB  +  -  Characterizes  page-oriented  TOs  in  digital  form  con¬ 

taining  tagging  information  to  allow  electronic  display  of 
variant  documents  with  efficient  access  to  internal  and 
external  reference  points  for  easy  retrieval  of  related 
information  (i.e.,  graphics,  tables,  other  TOs,  etc.). 

Type  C-  -  Characterizes  integrated,  interactive  data  m  digital  fonn 

containing  tagging  information  to  allow  efficient  access 
via  electronic  display  to  views  defined,  controlled  and 
verified  at  Tier  2. 

Type  C  -  Characterizes  integrated,  interactive  data  in  digital  form 

containing  tagging  information  to  allow  efficient  access 
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via  electronic  display  to  data  views  defined  Ly  each  Work 
Area  user  (and  therefore,  not  pre-vtrified  at  Tier  2). 


LIST  OF  ACRONYMS 


ACVC 

ADA 

ADADL 

AF 

AFAA 

AFCC 

AFCSA 

AFIS 

AFLC 

AFR 

AFSC 

AFTO 

AFTOMA 

AFTOMD 

AFTO  MS 

AFT022 

AFT0252 

AGMC 

AI 

AITI 

ALC 

ALCS 

ALS 

AM  PE 

ANSI 

APSE 

ASCII 

ASD 

ATC 

ATF 

ATI 

ATOS 

ARPANET 


A 

Ada  Compiler  Validation  Capability 
Programming  Language  (MII^STD-1815) 

Ada  Design  and  Documentation  Language 
Air  Force 

Air  Force  Audit  Agency 

Air  Force  Communications  Command 

Air  Force  Computer  Systems  Architecture 

Air  Force  Intelligence  Service 

Air  Force  Logistics  Command 

Air  Force  Regulation 

Air  Force  Systems  Command 

Air  Force  Technical  Order 

Air  Force  Technical  Order  Management  Administration 

Air  Force  Technical  Order  Management  Data 

Air  Force  Technical  Order  Management  System 

Air  Force  Technical  Order  Form  22 

Air  Force  Technical  Order  Form  252 

Aerospace  Guidance  and  Metrology  Center 

Artificial  Intelligence 

Automated  Interchange  of  Technical  Information 

Air  Logistics  Center 

Airlift  Control  Squadron 

Ada  Language  System 

Automated  Message  Processing  Equipment 

American  National  Standard  Institute 

Ada  Programming  Support  Environment 

American  Standard  Code  for  Information  Interchange 

Aeronautical  Systems  Division 

Air  Force  Training  Command 

Advanced  Tactical  Fighter 

Automated  Technical  Information 

Automated  Technical  Order  System 

ARPA  Network 
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BBN 

BRI 

BSD 

BSD 


CAD/CAM 

CALS 

CAMS 

CASE 

CATV 

CCITT 

CD-I 

CD-ROM 

CGM 

CNWDI 

COBOL 

CODASYL 

CO  M  SEC 

COTS 

CPIN 

CPU 

CSMA/CD 

CTN 

CTOC 

CTODO 


DACCS 

DBMS 

DDL 

DDN 

DDS 

DEC 

DI 

DMS 

DoD 

DODIIS 

DOE 


B 

Bolt,  Beranek  &  Newman,  Inc. 

Basic  Rate  Interface 
Ballistic  Systems  Division 

Berkeley  Standard  Distribution  (of  a  UNIX  operating  system) 

c 

Computer  Aided  Design/Computer  Aided  Manufacturing 
Computer-aided  Acquisition  and  Logistic  Support 
Core  Automated  Maintenance  System 
Computer  Aided  Support  Environment 
Community  Antenna  (Cable)  Television 

Consultative  Committee  for  International  Telephone  and  Telegraph 

Compact  Disk  -  Interactive 

Compact  Disk-Read  Only  Memory 

Computer  Graphics  Metafile 

Critical  Nuclear  Weapon  Design  Information 

Common  Business  Oriented  Language 

Conference  of  Data  Systems  Languages 

Communication  Security 

Commercial  Off-The-Shelf  Software 

Computer  Program  Identification  Number 

Central  Processing  Unit 

Collision  Sense  Multiple  Access  with  Collision  Detection 
CALS  Test  Network 
Commodity  Technical  Order  Center 
Consolidated  Technical  Order  Distribution  Office 

D 

Digital  Access  Cross  Connect  Systems 
Database  Management  System 
Document  Description  Language 
Defense  Data  Network 
Digital  Dataphone  Service 
Digital  Equipment  Corporation 
Document  Instance 
Document  Management  System 
Department  of  Defense 

Department  of  Defense  Intelligence  Information  System  (DIA) 
Department  of  Energy 
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DOROFILE 

DOT 

DRDS 

DTD 

DTOMA 


ECC 

ECP 

EDI 

EMI 

EOD 

ESD 


FD 

FDDI 

FMS 

FORTRAN 

FOSI 

FRD 

FSED 

FT  AM 

FTP 

FY 

4GL 


GOSIP 

G022 

GUI 


HDLC 

HIPO 

HP 

HQ 

HW 


IAvV 

IBM 


Commercial  Optical  Disk  Product  Name 

Department  of  Transportation 

Distributed  Relational  Database  System 

Data  Type  Definition  or  Document  Type  Definition 

Development  Technical  Order  Management  Agency  (pre-PMRT) 

E 

Error  Checking  and  Correction 
Engineering  Change  Proposal 
Electronic  Data  Interchange 
Electro-magnetic  Interference 
Explosive  Ordnance  Disposal 
Electronic  Systems  Division 

F 

Functional  Description 

Fiber  Data  Distribution  Interface 

Foreign  Military  Sales 

Formula  Translation  Programming  Language 
Formatting  Output  Specification  Instances 
Formerly  Restricted  Data 
Full-Scale  Engineering  Development 
File  Transfer,  Access  and  Management 
File  Transfer  Protocol 

Fiscal  Year  (October  1-  next  September  30) 

Fourth  Generation  Language  for  DBMSs  generally 

G 

Government  Open  System  Interconnect  Protocols 
Logistics  Management  of  Technical  Orders  System  (USAF) 
Graphical  User  Interface 

H 

High-Level  Data  Link  Control 
Hierarchical  Input/Processing/Output 
Hewlett  Packard,  Inc. 

Headquarters 

Hardware 

I 

In  Accordance  With 
International  Business  Machines 
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IDE 

IEEE 

I/F 

IGES 

IMIS 

INFORMIX 

INGRES 

IOC 

IP 

ISO 

ISDN 

ITDS 


JMEM 


KMC 

KMS 


LAN 

LHITA 

LITA 

LLC 

LMTOS 

LSA 


MAC 

MAJCOM 

MAU 

MHS 

MINET 

MIO 

MIS 

MMEDU 

MM_R 

MPP 

MSD 


Interactive  Development  Environments 
Institute  of  Electrical  and  Electronics  Engineers 
Interface 

Initial  Graphics  Exchange  Standard 

Integrated  Maintenance  Information  System  (USAF) 

Commercial  RDBMS  product  name 
Integrated  Graphics  and  Retrieval  System 
a  commercial  RDBMS  product  name 
Initial  Operational  Capability 
Internet  Protocol 

International  Standards/Services  Organization 
Integrated  Services  Digital  Network 
Improved  Technical  Data  System 

J 

Joint  Munitions  Effectiveness  Manual 

K 
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SECTION  1:  INTRODUCTION 


1.1  BACKGROUND 

This  section  briefly  presents  a  historical  introduction  to  the  Air  Force  Technical  Order  Man¬ 
agement  System  (AFTOMS)  Proof-of-Concept  (POC)  for  FY89  through  QTR1  FY90.  Sec¬ 
tion  1  includes  three  main  topics: 

•  Computer-aided  Acquisition  and  Logistic  Support  (CALS)  program  and 
the  role  of  the  Transportation  Systems  Center  (TSC); 

•  AFTOMS  POC  strategy  and  task  approach  in  support  of  the  Air  Force  Lo¬ 
gistics  Center  (AFLC)  AFTOMS  System  Program  Office  (SPO);  and 

•  Structure  and  format  of  the  Technology  Issues  &  Alternatives  Report, 
which  documents  the  POC  findings. 

These  topics  provide  a  contextual  basis  for  understanding  the  remaining  portions  of  this 
Technology  Issues  &.  Alternatives  Report. 

CALS  PROGRAM  AND  TSC's  ROLE 

The  CALS  program  was  established  to  improve  weapon  system  reliability  and  maintainabil¬ 
ity,  and  to  reduce  the  costs  of  weapon  system  acquisition  and  support.  One  major  continuing 
objective  of  the  CALS  program  is  to  improve  the  flow  of  technical  information  by  introducing 
automated  techniques.  The  automation  process  is  intended  to  improve  the  delivery  and  han¬ 
dling  of  large  quantities  of  technical  data.  CALS  will  significantly  reduce  the  amount  of  paper 
and  labor  needed  to  enter,  manipulate,  transfer,  and  interpret  this  data. 

In  June  1985,  a  joint  industry/Department  of  Defense  (DoD)  Tksk  Force  on  CALS  issued  a 
five  volume  report  (IDA  R-285)  which  presented  the  objectives  and  scope  of  the  program,  as 
well  as  a  top-level  management  and  implementation  plan.  The  task  force  concluded  that  the 
following  objectives  could  be  met: 

•  Design  more  supportable  weapon  systems; 

•  Support  transition  from  paper-based  to  digital-based  logistics  and  techni¬ 
cal  information  for  DoD  operations;  and 

•  Routinely  acquire  and  distribute  logistics  and  technical  information  in  digi¬ 
tal  form  for  new  and  existing  weapon  systems. 

The  Joint  Task  Force  recognized  that  in  order  to  implement  the  target  CALS  program  expedi¬ 
tiously,  efforts  within  the  armed  forces  must  be  coordinated  to  focus  on  the  CALS  architec¬ 
ture.  The  DoD  directed  each  service  to  create  a  permanent  CALS  Management  Information 
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Office  (MIO)  as  the  official  focal  point  for  coordination  of  its  logistics  automation  strategies 
and  programs. 

On  18  October  1985,  Program  Management  Directive  (PMD)  number  5260(1),  Automation 
of  Technical  Information  and  Computer  Aided  Logistics  Support  (CALS),  established  the 
CALS  program  and  chartered  the  Air  Force  MIO  at  HQ  Air  Force  Systems  Command 
(AFSC)  to  coordinate  and  manage  the  CALS  program.  In  addition,  the  PMD  identified  the 
following  tasks: 

•  Plan  for  the  integration  of  all  existing  Automated  Technical  Information 
(ATI)  projects  within  a  standard  information  systems  framework; 

•  Determine  the  full  range  of  CALS  objectives  and  management  concepts; 

•  Plan  large-scale  demonstrations  and  implementation  of  CALS  technology 
for  a  weapon  system  acquisition  program; 

•  Ensure  system  structures  are  consistent  and  comply  with  Air  Force  guide¬ 
lines; 

•  Perform  a  cost  benefit  analysis  of  replacing  present  technical  information 
management  methods  with  automated  methods;  and 

•  Prepare  and  maintain  an  ATI  and  CALS  Program  Management  Plan 
(PMP),  addressing  program  integration  and  consolidation  of  CALS  proce¬ 
dures  as  well  as  incorporation  of  improved  ATI  capabilities. 

The  MIO  identified  three  areas  of  technical  information  for  review  and  improvement: 

•  Technical  Orders  (TOs); 

•  Product  Definition  Data  (PDD);  and 

•  Logistics  Support  Analysis  (LSA). 

In  1986,  TSC  of  the  Department  of  Transportation  (DOT)  was  contracted  by  the  CALS  MIO 
to  provide  systems  engineering  support  to  create  automation  plans  for  these  areas.  These 
automation  plans  define  a  concept  of  operations,  management  strategies,  implementation 
plan,  and  a  cost-benefit  analysis.  The  initial  activity  consisted  of  review  and  analysis  of  exist¬ 
ing  programs  and  standards.  In  1987,  the  focus  of  this  activity  centered  on  developing  a  7-10 
year  automation  plan  for  TOs.  Appendix  A  describes  the  modular  planning  process  used  and 
the  resulting  AFTOMS  Automation  Plan.  This  plan  offers  the  reader  a  valuable  overview  of 
the  As-Is  problems,  the  proposed  To-Be  TO  system  concept,  and  an  introductory  description 
of  TO  data  handling  and  AFLC  infrastructure  concepts  needed  to  understand  this  Technology 
Issues  &  Alternatives  Report  as  well  as  the  POC  findings. 

1.2  AFTOMS  PROOF  OF  CONCEPT  (POC) 

The  MIO  is  responsible  for  initially  investigating  and  planning  CALS  programs,  exclusive  of 
the  implementation  responsibility  for  any  specific  system,  such  as  AFTOMS.  Responsibility 
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for  AFTOMS  definition,  development,  and  deployment  was  assigned  in  FY88  to  the  AFLC. 
This  command  established  an  AFTOMS  SPO,  located  at  Wright  Patterson  Air  Force  Base 
(WPAFB),  to  manage  all  necessary  work  in  implementing  the  AFTOMS  concept.  After  publi¬ 
cation  of  th eAFT OMS  Automation  Plan-Final  Report,  February  1988,  TSC  supported  the  SPO 
in  building  consensus  within  the  Air  Force  to  support  the  AFTOMS  To-Be  concept  and  in 
planning  the  F"Y89  POC  work. 

The  purpose  of  the  POC  is  to  investigate  the  AFTOMS  concept  in  more  depth,  using  the  fol¬ 
lowing  approaches: 

•  Systematically  identifying  and  assessing  its  benefits  and  risks; 

•  Finding  approaches  for  avoiding  or  abating  those  risks;  and 

•  Identifying  any  previously  overlooked  opportunities,  thus  providing  early 
technical  input  to  the  SPO  that  can  be  used  to  leverage  and  enhance  AF¬ 
TOMS  success. 

Such  input  (perhaps  repackaged  by  the  SPO)  could  also  support  preparation  of  the  Request 
For  Proposal  (RFP)  technical  data  package,  source  selection  criteria  for  evaluating  RFP  re¬ 
sponses  from  contractors,  and  various  AFLC  and  DoD  program  reviews. 

1.2.1  POC  Strategy 

The  resulting  POC  strategy  for  TSC  support  during  1  October,  1988  to  31  December,  1989  is 
graphically  depicted  in  FIGURE  1-1.  This  strategy  has  three  major  and  interacting  activities, 
each  of  which  has  its  own  significant  characteristics  and  deliverables: 

•  Prototyping  a  Demo  System; 

•  Evaluating  technologies  and  identifying  risk  abatement  strategies:  and 

•  Performing  a  Feasibility  Study. 

PROTOTYPING  A  DEMO  SYSTEM 

The  Demo  System  focuses  on  understanding  and  implementing  key  aspects  of  the  To-Be  con¬ 
cept  functionality  using  technologies  and  products  that  are  suitable  for  AFTOMS  in  FY89.  In 
the  process,  much  invaluable  hands-on  experience  is  gained  in  working  with  current  and 
emerging  state-of-the-art  technologies,  integrating  technology  products  with  critical  AF¬ 
TOMS  functionality,  finding  and  evaluating  technological  and  operational  problem  areas, 
and  developing  a  visible  and  dynamic  basis  for  refining  AFTOMS  requirements.  The  deliver¬ 
able  is  a  packaged  Demo  System  to  be  installed  at  the  AFTOMS  SPO,  which  could  then  be 
used  to: 
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THE  BASELINED  TO-BE  MODEL  DROVE  THE 


FIGURE  1-1.  PROOF-OF-rONGEPT  (POC)  STRATEGY 


•  Provide  a  model  for  refining  RFP  requirements,  t  ser  interfaces,  and  source 
selection  criteria  to  reinforce  a  coordinated  and  tested  view  of  AFTOMS; 

•  During  AFTOMS  FSED,  serve  as  a  low-cost  system  test  bed  for  indepen¬ 
dently  evaluating  critical  technical  problems  and  alternative  solutions  with¬ 
out  disrupting  the  main  AFTOMS  development  effort; 

•  Provide  a  dynamic  test  bed  for  developing  user  training  approaches  and 
materials; 

•  Provide  a  hands-on  training  vehicle  for  prime  contractor  developers  and  IV 
&V  contractor  evaluators;  and 

•  Demonstrate  AFTOMS  to  managers  and  users  from  USAF,  DoD,  and  in¬ 
dustry. 

TECHSOLOGY  EVALUATION 

The  technology'  evaluation  activity  consists  of  a  primary,  hands-off  path  that  is  supported  by 
limited  hands-on  evaluations  of  selected  technologies  and/or  products  not  incorporated  into 
the  Demo  System.  The  primary  path’s  evaluation  focus  is  quite  broad,  including  investigation 
of  To-Be  requirements,  integration  issues,  advanced  technologies,  standards,  system  build- 
ability  and  operational  utility  issues,  as  well  as  interoperability7  with  other  Air  Force  systems. 
This  broad,  systematic  approach  makes  its  findings  particularly  suitable  for  input  into  the 
RFP  and  source  selection  work  being  done  at  the  AFTOMS  SPO,  but  its  findings  are  also 
valuable  to  the  prime  development  and  IV  &  V  contractors.  The  deliverable  for  this  activity  is 
the  Technology7  Issues  &  Alternatives  Report.  Significant  and  relevant  requirement  and  tech¬ 
nology  findings  from  the  other  two  activities  (prototyping  a  Demo  System  and  the  Feasibility7 
Study)  are  also  integrated  into  this  Technology  Issues  &  Alternatives  Report. 

Feasibility  Study 

The  Feasibility  Study  activity,  performed  by  TSC,  focuses  both  on  the  As-Is  environment  and 
the  To-Be  concept  to  perform  an  operational  and  economic  feasibility  assessment  of  AF¬ 
TOMS.  The  deliverable  is  a  Feasibility  Report  which  is  used  by  the  SPO  to  develop  and  justify 
the  AFfOMS  program  funding.  In  addition,  this  document  is  part  of  the  SPO’s  AFTOMS 
Economic  Analysis  Report. 

An  adequately  detailed  To-Be  model  drives,  focuses,  and  integrates  these  three  activities 
(prototyping  a  Demo  System,  technology  evaluation,  and  Feasibility  Study),  and  is  described 
in  Section  1.2.2.  Use  of  the  three  POC  deliverable  products  is  a  SPO  responsibility. 

1.2.2  To-Be  Concept  Elaboration  into  the  To-Be  Model 

An  initial,  high-level,  TO  system  concept  for  AFTOMS  was  developed  for  the  Automation 
Plan  and  is  described  in  Appendix  A  However,  more  detail  was  required  for  the  concept  to 
be  useful  as  a  basis  for  either  POC  work  or  development  of  RFP  requirements,  and  as  a  com- 
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mon,  integrated,  coordinated,  and  approved  concept.  Therefore,  a  Might-Be  representation 
was  developed  in  January  1989  for  use  in  the  POC  work.  In  June  1989,  the  Might-Be  was 
adopted  as  the  high-level  To-Be  Model,  serving  as  the  core  from  which  to  develop  AFTOMS 
requirements. 

An  overview  of  the  baselined  To-Be  Model  is  shown  in  FIGURE  1-2.  The  To-Be  Model 
views,  analyzes,  and  characterizes  AFTOMS  from  the  six  important  perspectives  listed  on  the 
left  side  of  the  figure.  Each  perspective  is  then  decomposed  in  a  modular,  hierarchical  fashion 
to  the  level  of  detail  needed  for  the  POC.  In  this  way,  the  To-Be  drives  the  POC  work. 


SIGNIFICANT 

CHARACTERISTICS 

OF  THE  TO-BE 
BASELINE 

•  Operational 
Environment 

•  System 
Functionality 

•  User  Interfaces 
and  Usability 

•  System  Capacities 
and  Performance 

•  Required 
Technologies 

•  System 
Implementation 
Issues 


FIGURE  1-2.  AFTOMS  TO-BE  BASELINE:  STRUCTURAL  OVERVIEW 

This  To-Be  Model  has  been  coordinated  within  the  AFTOMS  community,  even  though  it  is 
not  a  POC  deliverable.  Its  predecessor,  the  Might-Be  presentation,  was  presented  at  the  Jan¬ 
uary  1989  Program  Management  Review  (PMR),  then  released  for  review  and  comment. 
Comments  were  received  in  March,  incorporated,  and  the  Might-Be  presentation  was  re- 
released  on  April  1, 1989  as  Appendix  G  of  the  Feasibility  Study  (first  draft).  Further  refine¬ 
ments  were  made  to  obtain  the  current  version  provided  separately  to  the  SPO  as  a  draft  doc¬ 
ument,  where  it  will  reside  for  the  remainder  of  the  POC.  The  format  and  essence  of  the 
Might-Be  document  have  not  changed  throughout  this  period. 


1.2.3  Risk  Abatement  Focus 

The  focus  of  AFTOMS  POC  work  is  risk  abatement.  Fundamentally,  risk  abatement  is 
achieved  by  developing  a  thorough  project  understanding  using  a  balanced  combination  of 
the  following  techniques: 

•  Through  hands-off  methods  requiring  detailed  analysis: 

o  Exploring  the  To-Be  concept  analytically  and  systematically  to  iden¬ 
tify  and  evaluate  logical  needs,  problems,  and  consequences;  and 

•  Through  hands-on  Demo  System  or  technology  evaluation  work: 

o  Prototyping  to  test  and  verify  the  analysis,  evaluate  technologies  and 
products  relative  to  the  specific  needs  of  AFTOMS,  and  to  disclose 
subtle  integration  problems  overlooked  in  the  analysis. 

The  value  of  obtaining  such  a  thorough  project  understanding  before  defining  and  building 
the  real  system  is  practical  and  significant.  It  anticipates  opportunities  and  resolves  problems 
that  could  appear  later,  thereby  reducing  the  total  development  burden  during  Full-Scale 
Engineering  Development  (FSED).  It  also  provides  a  coherent,  integrated,  and  AFTOMS- 
specific  .Tamework  for  quicker  evaluation  and  resolution  of  problems  and  exploits  the  oppor¬ 
tunities  that  may  arise  in  the  future. 

The  benefits  of  this  framework  involve  the  reduction  of  project  risk  by  reducing: 

•  Surprises  and  unintended  consequences  downstream; 

•  Changes  and  iterations  during  development; 

•  Schedule  slippages; 

•  Compromises  in  delivered  functionality,  performance,  and  system  qualify"; 

•  Follow-on  Engineering  Change  Proposals  (ECPs)  to  fund  after  project 
completion;  and 

•  Providing  a  means  to  prototype  high-risk  options  in  a  limited  environment 
without  burdening  and  jeopardizing  the  full-scale  effort  with  avoidable 
problems. 

This  framework  can  also  be  used  to  train  system  developers,  IV&V  contractor  personnel,  and 
others,  to  understand  the  AFTOMS  requirements  and  technologies  more  quickly,  thereby 
shortening  the  learning  curve  and  providing  a  partial  substitute  for  any  lack  of  AFTOMS- 
relevant  experience;  this  will  focus  development  activities  and  increase  productivity. 

To  realize  these  significant  benefits,  however,  the  POC  must  be  a  continued  effort  throughout 
the  AFTOMS  pre-award,  design,  development,  and  deployment  phases  (FY89-FY95).  It  must 
be  rightly  conceived,  well  executed,  and  up-front  in  the  project  cycle  to  maximize  its  down- 
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stream  leverage;  POC  findings  must  be  integrated  into  all  subsequent  phases  of  the  project  so 
that  there  is  a  consistency  of  approach,  and  its  detailed  lessons  observed  when  specific  issues 
are  worked  on  an  on-going  basis. 

The  FY89-FY90  POC  approach  focuses  on  AFTOMS,  its  operating  environment,  important 
risk  issues,  and  two  time  frames:  FY89  to  develop  a  current  assessment  of  technologies,  prod¬ 
ucts,  integration  problems,  and  other  risks;  and  FY91-FY93  to  project  future  assessments  of 
these  technologies,  products,  problems,  and  risks  to  the  time  frame  when  tb.  full-scale  AF¬ 
TOMS  is  designed  and  built. 

The  POC  approach  is  disciplined  to  investigate  important  issues  of  consequence  to  AF¬ 
TOMS.  It  is  a  multidimensional  approach  that  incorporates  users,  work  procedures,  opera¬ 
tional  constraints,  technologies,  and  interfacing  issues.  It  is  also  integrated,  making  use  of  the 
comparative  advantages  of  various  techniques  to  explore  different  aspects  of  issues,  then  bal¬ 
ancing  and  combining  those  investigations  and  results  to  get  overall  coverage  and  synergy. 
Finally,  it  is  an  action-oriented  methodology  designed  to  make  its  findings  clear  and  easy  to 
refine/update  throughout  the  project  life  cycle. 

For  example,  consider  the  maturity  and  multidimensional  productivity  of  this  POC  approach. 
Aside  from  the  personal  maturity  and  relevant  defense  industry  and  systems  experience  of 
TSC's  POC  staff,  there  is  a  general  framework  which  can  be  and  was  used  to  evaluate  the 
operational  readiness  of  emerging  technology  products  for  use  in  AFTOMS.  In  this  frame¬ 
work,  every  complex  emerging  technology  follows  a  development  path  which  is  unique  in  its 
details,  yet  similar  when  normalized  and  viewed  at  a  broader  level.  Thus,  if  the  progress  of 
that  development  path  is  charted  over  time  as  depicted  in  FIGURE  1-3,  then  a  common  gen¬ 
eral  pattern  emerges.  The  horizontal  axis  represents  time  measured  in  multiples  of  the  aver¬ 
age  product  generation  duration  for  that  technology;  the  vertical  axis  represents  the  scatter, 
diversity,  or  degree  of  uniqueness  of  functionality  and  performance  advantage  across  the 
technology  products. 

When  a  technology  concept  is  first  formulated,  it  may  be  incomplete  and  its  practical  utility 
may  not  be  initially  obvious.  If  several  independent  people  or  organizations  were  to  imple¬ 
ment  an  important  aspect  of  the  concept,  the  resulting  early  product  implementations  would 
typically  display  large  differences  in  functionality,  performance,  constraints,  etc.,  when  com¬ 
pared  to  one  another.  In  addition,  a  good  chance  exists  that  these  different  products  will  be 
distributed  informally  or  sold  to  other  users,  thereby  exposing  the  products  to  two  major  types 
of  conforming  pressures: 

•  The  demand-side  conforming  pressure  from  diverse  users  of  each  product 
who  provide  operational  feedback  to  correct  problems,  add  features,  relax 
constraints,  or  suggest  performance  improvements  to  make  the  product 
more  valuable  to  their  needs;  and 
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•  The  supply-side  conforming  pressure  from  the  product  marketers  to  out¬ 
do  their  competitors  by  offering  competitive  capabilities  enhanced  with  a 
few  extra  discriminating  capabilities. 


EXPLORATIONS 


LEGEND 

B  represents  a  Beta  version  of  a  product  release 
C  represents  a  pre-product  concept  implementation 
R.  represents  version  n  of  a  product  release _ 


FIGURE  1-3.  COMPETITIVE  EVOLUTION  OF  PRODUCTS 

Given  these  continuing  pressures,  and  the  fact  that  it  takes  at  least  two  years  to  develop  a  next 
generation  or  major  release  of  a  new  product  in  a  complex  technology,  FIGURE  1-3  supports 
the  following  conclusions: 

•  It  takes  a  few  generations  for  competing  products  to  offer  common,  solid, 
operationally  tested,  and  useful  capabilities;  and 

•  Some  degree  of  de  facto  standardization  of  capabilities  emerges  over  time. 

This  framework  and  these  principles  can  be  used  to  assess  the  maturity  of  current  technolo¬ 
gies  and  project  status  of  future  generations  of  technologies. 

In  reference  to  POC  productivity,  FIGURE  1-4  summarizes  the  strengths  of  hands-off  stu¬ 
dies  versus  the  strengths  of  hands-on  Demo  System  development  activities,  and  supports  the 
fact  that  the  two  techniques  have  to  be  combined  so  an  effective  risk  abatement  approach  can 
be  obtained. 
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A  PRODUCTIVE 
R I SK  ABATEMENT  APPROACH 


IS  BEST  REALIZED  BY  COMBINING  THE 
STRENGTHS  OF: 

•  HANDS-OFF  STUDIES 

•  EXPLORE  ISSUES  NOT  POSSIBLE  OR  EASILY  PERFORMED  WITH  A  DEMO 
SYSTEM: 

•  ALTERNATIVE  TECHNOLOGIES  OR  PRODUCTS  NOT  USED  IN 
THE  DEMO  SYSTEM 

.  IMPACTS  OF  FORESEEABLE,  BUT  IMMATURE  EMERGING 
TECHNOLOGIES  /TOOLS 

.  REQUIREMENTS  NOT  IMPLEMENTED  IN  THE  DEMO  SYSTEM 

.  TRANSLATIONS  TO  DIFFERENT  ENVIRONMENTS,  CONSTRAINTS, 
USERS,  TIMEFRAMES 

.  THE  TLIT1ES",  E  G.,  MAINTAINABILITY,  RELIABILITY,  ETC. 

•  EXPLORE  BROADER  ISSUES:  INTEGRATION,  INTEROPERABILITY, 
STANDARDS,  ETC. 

•  PROVIDE  A  REPORT  FORMAT:  FAMILIAR,  CONTROLLABLE,  AND 
USABLE  PRESENTATION 


•  HANDS-ON  DEMO  DEVELOPMENT 

•  IDENTIFY  FALSE  PATHS  EARLIER  BY  EXPLORING  COMPLETENESS  AND 
CONSISTENCY  OF  THE  REQUIREMENTS 

•  EXPLORE  SYSTEM  INTEGRATION  AND  BUILD  ABILITY  ISSUES  CLOSER 

•  PERFORM  PRACTICAL  EVALUATIONS  OF  PRODUCTS,  TOOLKITS,  AND 
STANDARDS 

•  ELICIT  AND  EVALUATE  USER  REACTIONS  TO  DEMO  SYSTEM 
FUNCTIONALITY  and  USER  INTERFACE  FORMATS 

•  PROVIDE  A  MODIFIABLE  TEST  BED  SYSTEM  FOR  EVALUATING 
PROPOSED  CHANGES  OR  PROBLEMS  ARISING  DURING 
DEVELOPMENT 

•  PROVIDE  A  DEMONSTRATION  and  TRAINING  VEHICLE  FOR 
MANAGERS,  USERS,  DEVELOPERS,  AND  OTHERS.  (I  E..  A  MODERN 
INTERACTIVE  COMMUNICATION  VEHICLE) 


I 

FIGURE  1-4.  RISK  ABATEMENT  APPROACH 

I 
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1.3  TECHNOLOGY  ISSUES  &  ALTERNATIVES  REPORT 


The  Technology  Issues  &  Alternatives  Report  documents  the  results  of  POC  findings  for  the 
following: 

•  AFTOMS  requirements; 

•  Risks; 

•  Opportunities; 

•  Technology  and  integration  lessons  learned;  and 

•  Risk  abatement  recommendations. 

These  findings  were  based  on  designing  and  building  the  Demo  System,  conducting  other 
hands-on  technology  evaluations,  and  completing  the  POC  hands-off  analytical  activities.  To 
make  this  report  usable  and  actionable  despite  its  length,  it  has  been  given  a  unique,  modular 
structure. 

1.3.1  Report  Structure 

The  Technology  Issues  &  Alternatives  documentation  package  consists  of  two  complementa¬ 
ry  reports: 

•  This  public  report,  the  Technology  Issues  &  Alternatives  Report  dated  De¬ 
cember  1989,  which  is  free  of  proprietary  product  mentions  and,  therefore, 
is  suitable  for  general  distribution;  and 

•  A  private  report,  the  Supplement  to  the  Technology  Issues  &  Alternatives 
Report,  issued  only  in  final  draft  form  for  AFTOMS  SPO  use  because  it 
contains  the  remaining  technology  material  that  mentions  proprietary 
products  to  help  the  SPO  understand  risk  issues  better. 

THE  PUBLIC  REPORT 

The  high-level  structure  for  the  public  Technology  Issues  &  Alternatives  Report  is  illustrated 
in  FIGURE  1-5.  The  report  consists  of  a  main  report,  followed  by  two  appendices: 

•  Appendix  A — Contains  background  material  and  an  overview  of  the  To-Be 
system  concept;  and 

•  Appendix  B — Contains  eight  sections,  each  of  which  explores  an  important 
dimension  of  integration. 

These  appendices  do  not  focus  on  specific  technology  product  details  and  comparisons  to 
avoid  biasing  AFTOMS  proposal  responses. 
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TECHNOLOGY  ISSUES  &  ALTERNATIVES  REPORT 

STRUCTURE 
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FIGURE  1-5.  TECHNOLOGY  ISSUES  AND  ALTERNATIVES  REPORT  STRUCTURE 


The  main  report  is  short,  general  in  the  level  of  presentation,  actionable  in  the  presentation  of 
risk  abatement  recommendations,  and  also  free  of  specific  product  mentions.  Consequently, 
the  report  can  be  read  by  managers,  and  can  be  used  as  an  attachment  to  the  RFP  package  or 
for  general  distribution.  The  core  of  this  main  report  is  contained  in  its  Sections  2  and  3, 
which  summarize  in  tabular  form,  the  detailed  findings  in  Appendix  B  and  the  separate  draft 
Supplement  report,  respectively.  Section  4  of  the  main  report  summarizes  POC  findings  and 
conclusions. 

THE  PRIVATE  REPORT 

The  high-level  structure  for  the  private  Supplement  is  illustrated  in  FIGURE  1-6.  This  Sup¬ 
plement  also  consists  of  a  main  report,  followed  by  two  appendices. 

•  Appendix  A — Contains  the  detailed  POC-developed  AFTOMS  To-Be 
Model;  and 

•  Appendix  B — Contains  sixteen  sections,  each  of  which  explores  an  impor¬ 
tant  area  of  technology. 

These  appendices  include  specific  technology  product  details,  comparisons,  and  findings 
which  can  be  useful  for  evaluating  AFTOMS  proposal  responses,  but  makes  this  Supplement 
unsuitable  for  general  distribution. 

The  main  report  in  the  Supplement  parallels  the  main  portion  of  the  public  report  to  main¬ 
tain: 


•  Similarity  of  structure,  between  public  and  private  reports; 

•  Standalone  usefulness  of  the  Supplement;  and 

•  Consistency  of  numbering  in  reused  material. 

The  front-end  material  (i.e.,  Preface  through  the  Introduction)  in  the  Supplement,  is  an 
adapted  version  of  that  appearing  in  the  public  report;  Section  2  is  left  intentionally  blank 
since  in  the  public  report  it  overviews  dimensions  of  integration  which  are  irrelevant  to  this 
Supplement;  and  Section  3  is  reused  from  the  public  report  because  it  succinctly  overviews  the 
individual  technology  reports  contained  in  Appendix  B,  thereby  making  this  Supplement  us¬ 
able  in  a  standalone  fashion. 

13.2  Risks  Evaluated 

Before  the  POC  effort  began,  the  prevailing  opinion  within  the  AFTOMS  community  was 
that  reliance  on  state-of-the-art  and  emerging  technologies  posed  the  greatest  risks  to  proj¬ 
ect  success.  However,  the  early  part  of  the  POC  effort  focused  on  refining  the  To-Be  concept 
and  evaluating  numerous  candidate  technology  products;  and,  it  became  apparent  that  there 
were  more  significant  risks  present  in  various  dimensions  of  integration. 
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ISSUES  &  ALTERNATIVES  REPORT 


Therefore,  the  POC  scope  was  amended  to  incorporate  eight  additional  risk  evaluations  of 
integration  issues  in  addition  to  the  sixteen  technology  risk  evaluations,  thereby  providing  a 
more  complete  and  thorough  report.  The  eight  dimensions  of  integration  are  listed  in  main 
report  Section  2.1;  and  the  sixteen  individual  technologies  are  listed  in  Section  3.1. 

Each  of  these  risk  evaluation  choices  has  a  potential  near-term  or  long-term  relevance  for 
AFTOMS.  Other  technologies  were  not  evaluated  since  their  unique  capabilities  were  not 
needed  to  implement  the  To-Be  concept.  For  example,  initially  it  was  thought  that  Artificial 
Intelligence  (Al)  technology  could  be  used  for  profile  registration;  however,  subsequent  ex¬ 
amination  showed  that  proven  relational  database  techniques  could  implement  the  concept, 
would  be  simpler  and  less  risky  to  work  with,  more  predictable  in  processing  results,  and  easi¬ 
er  to  modify  without  the  need  for  extensive  reverification. 

1.3.3  Format  Modularity  and  Consistency 

Evaluation  of  each  of  the  sixteen  technology  risk  areas  and  documentation  of  POC  findings  is 
focused  on  the  needs  of  AFTOMS,  and  presented  in  a  modular  consistent  format  in  Appendix 
B  of  the  separate  draft  Supplement.  For  evaluation  of  each  of  the  sixteen  technologies,  this 
format  includes  the  following  sections: 

•  Scope  and  Relevance:  Addresses  why  this  technology  is  important  io  AF¬ 
TOMS; 

•  State  of  the  Technology  :  Focuses  on  how  the  technology  has  developed,  its 
FY89  state,  and  projections  for  FY91-FY93; 

•  Leading  Suitable  Product  Contenders:  Identifies  a  few  leading  product  ex¬ 
amples  of  this  technology  suitable  for  the  AFTOMS  environment,  assesses 
their  current  state,  and  projects  their  potential  state  in  FY91-FY93; 

•  Technology  Products  Used  in  AFTOMS  POC:  Summarizes  significant  find¬ 
ings  from  POC’s  hands-on  experience  with  specific  products; 

•  Risk  Assessment:  Summarizes  the  residual  risks  posed  by  this  technology 
for  use  in  AFTOMS;  and 

•  Risk  Abatement:  Offers  actionable  approaches  for  avoiding,  mitigating,  or 
managing  such  risks. 

Similarly,  for  evaluation  of  each  of  the  eight  integration  dimensions,  the  loosely  standardized 
format  includes  the  following  sections  (with  some  variations): 

•  Scope  and  Relevance:  Addresses  why  this  integration  dimension  is  impor¬ 
tant  to  AFTOMS; 

•  State  of  Integration  Feasibility:  Focuses  on  how  integration  feasibility  has 
developed,  its  FY89  state,  and  projections  for  FY91-FY93; 
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•  Particular  Integration  Approaches  Used  in  AFTOMS  POC:  Summarizes 
significant  findings  from  POC’s  analytical  evaluation  and  hands-on  experi¬ 
ence  with  technology  products; 

•  Risk  Assessment;  Summarizes  the  residual  risks  posed  by  this  integration 
dimension  for  AFTOMS;  and 

•  Risk  Abatement:  Offers  actionable  approaches  for  avoiding,  mitigating,  or 
managing  such  risks. 


The  benefits  of  such  format  standardizations  include: 

•  Easy  reading  to  find  material  of  interest; 

•  Consistent  level  of  coverage  across  topics; 

•  Ease  of  integration  of  the  findings  within  the  report:  and 

•  Ease  of  translation  of  findings  into  specific  RFP  requirements. 
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SECTION  2:  TECHNICAL  ASSESSMENT  OF 
TECHNOLOGY  INTEGRATION  DIMENSIONS: 

OVERVIEW 


2.1  INTRODUCTION 

Heterogeneity  is  at  the  heart  of  AFTOMS  since  AFTOMS  supports  heterogeneity'  in  func¬ 
tionality’,  user  location,  user  types,  hardware,  standards,  and  data;  and  provides  interfaces  to 
Air  Force  and  contractor  systems.  Therefore,  AFTOMS  can  be  built  either  by: 

•  Custom  developing  and  integrating  all  required  capabilities;  or 

•  Just  custom  integrating  commercially-available  technology  products,  each  of 
which  offers  an  integrated  subset  of  different  functionalities  that  partially  satis¬ 
fies  AFTOMS  needs. 

The  custom  development  alternative  is  not  feasible  given  the  AFTOMS  development  budget, 
ambitious  project  schedule,  and  the  unacceptable  levels  of  risk  that  would  accompany  any  Air 
Force  attempt  to  duplicate  the  functionality,  performance,  and  operational  reliability'  of  ma¬ 
jor  technolog>'  software  products  (such  as  DMS,  RDBMS,  UIMS,  ODS,  etc.). 

The  second  alternative  of  custom  integration  is  at  least  feasible  if  not  easy  and  risk  free.  Thus, 
AFTOMS  should  be  developed  by  integrating  relevant  technolog}  products;  much  of  the  sys¬ 
tem's  resulting  uniqueness  and  operational  usefulness  will  come  from  the  choice  and  blend¬ 
ing  of  technologies  and  products  selected,  and  their  subsequent  integration  into  a  seamless 
whole. 

Such  integration  poses  an  extra  layer  of  integration  risk  beyond  the  contributing  technologi¬ 
cal  risks  posed  by  each  technolog}'  (summarized  in  Section  3.3).  Given  the  uniqueness  of  the 
technology  mix,  capabilities  used  selectively,  and  the  custom  software  written  to  unify  them 
into  one  seamless  system,  the  integration  risk  could  actually  exceed  the  total  technological 
risk  associated  with  particular  products.  This  viewpoint  identifies  the  critical  importance  and 
contribution  of  integration  risk  to  a  proper  and  thorough  risk  abatement  evaluation. 

2.2  INTEGRATION  RISK 

Factors  affecting  the  integration  risk  are  numerous  and  complex  as  are  the  short  and  long 
term  evaluations  of  their  collective  influences  on  AFTOMS.  Integration  risk  must  be  eva¬ 
luated  from  several  points  of  view  (dimensions).  Within  each  dimension  there  are  risks;  these 
can  be  organized  and  evaluated  based  on  their  AFTOMS  impact. 

2.2.1  Dimensions 

The  eight  dimensions  in  which  integration  risk  is  relevant  to  AFTOMS  are  as  follows: 
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•  Management  of  distributed  user  functionality.  Focuses  on  reassessing  the  fea¬ 
sibility  of  the  AFTOMS  To-Be  model  in  terms  of  its  major  functionality  and 
how  that  functionality  is  distributed  over  networks  and  throughout  the  AF¬ 
TOMS  infrastructure; 

•  Handling  and  conversion  of  heterogeneous  technical  order  data.  Focuses  on 
managing  a  large  inventory  of  heterogeneous  TO  types  (paper,  digital  page 
image,  digital  interactive,  classified,  unclassified,  etc.)  and  TO  conversion  from 
paper  to  digital  to  maximize  automation  benefits; 

•  Support  of  heterogeneous  system  users.  Focuses  on  providing  automated  sup¬ 
port  to  a  wide  spectrum  of  system  users  whose  functions,  data,  and  information 
requirements  vary  significant!}", 

•  Use  of  electronic  communication.  Focuses  on  an  AFTOMS  communication  ar¬ 
chitecture  for  connecting  majoi  elements  of  the  system  and  organizations,  as 
well  as  passing  TO  content  and  management  data  among  S}Stem  users; 

•  Interface  to  other  Air  Force  functions/systems.  Focuses  on  interfaces  an  J  inter¬ 
operability  with  othei  Air  Force  systems,  organizations,  and  functions; 

•  System  buildability.  Focuses  on  factors  affecting  tuilding  an  efficient,  effec¬ 
tive  AFTOMS,  and  develops  a  framework  for  modeling  project  risk; 

•  Reliance  on  conformance  to  standards.  Focuses  on  th*  influence  of  standards 
on  system  architecture,  and  defines  a  framework  for  viewing  the  integration  of 
multiple  standards  and  their  associated  risks;  and 

•  Operational  utility.  Focuses  on  managerial  and  technological  approaches  for 
rapidly  achieving  automation  benefits,  promoting  productive  daily  use,  and 
supporting  long-term  effectiveness  of  AFTOMS. 

2.2.2  Risk  Evaluation 

Within  each  integration  dimension,  risk  can  arise  in  several  areas,  such  is: 

•  Functionality.  The  proposed  integration  cannot  provide  the  functionality 
needed  to  integrate  target  capabilities  because:  they  are  logically  inconsistent, 
the  necessary  knowledge  foundation  does  not  exist,  available  hardware  cannot 
support  that  functionality,  or  the  functionality  becomes  operationally  unac¬ 
ceptable; 

•  Performance.  The  proposed  integration  produces  unacceptable  performance 
in:  error  rate,  task  completion  time,  predictability  for  a  productive  work  pro¬ 
cess,  or  degradation  under  increased  loading; 
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•  Seamlessness.  The  proposed  integration  is:  not  smooth,  difficult  to  learn,  un¬ 
productive,  error  prone,  and  places  an  unnecessary  operational  burden  on  us¬ 
ers; 

•  Flexibility.  The  proposed  integration  is  logically  too  tightly  coupled  with  po¬ 
tentially  obsolete  or  proprietary  methods  and/or  products,  so  it  could  present 
future  problems  in  maintenance  and  upgradeability,  and 

•  Doability.  The  proposed  integration  may  not  be  accomplished  successfully 
within  the  constraints  of  the  project  given  the  technolog}’  products,  tools,  and 
support  available. 

Each  identified  integration  dimension  was  evaluated  for  its  degree  of  integration  risk  relative 
to  the  particular  needs  and  special  characteristics  of  the  AFTOMS  concept.  Evaluations  were 
performed  for  two  time  frames: 

•  FY89,  to  determine  its  current  feasibility  and  problems;  and 

•  FY91-FY93,  to  forecast  its  feasibility  and  risk  for  the  actual  development  and 
subsequent  use  of  AFTOMS. 

Risks  were  assessed  for  significance  using  the  following  judgmental  scale: 

•  High.  Characterizes  those  risks  of  wide-ranging  impact  that  can  significantly 
reduce  automation  benefits  or  jeopardize  AFTOMS  success; 

•  Medium.  Characterizes  those  risks  that  can  compromise  important  automated 
functionality  (relative  to  the  To-Be  system  concept)  and  degrade  productivity 
somewhat,  yet  not  jeopardize  either  the  automation  benefits  or  program  suc¬ 
cess;  and 

•  Low.  Characterizes  those  risks  that  have  small,  limited  impacts,  and  for  which 
solutions  will  be  defined  during  the  normal  development  process. 

2.2.3  Summary 

The  35  integration  risks  (or  classes  of  risks)  identified  during  the  POC  for  AFTOMS  are  orga¬ 
nized  by  integration  dimension  and  listed  on  the  right-hand  side  pages  of  TABLE  2-1,  as  are 
corresponding  suggested  approaches  for  abating  them.  Of  these  35: 

•  None  prevent  AFTOMS  from  being  developed  if  the  abatement  recommenda¬ 
tion  is  followed; 

•  Twelve  (12)  are  very  significant  in  severity: 

o  The  operational  ability  to  perform  Type  A-to-Type  B  document 
conversion  economically  for  a  complete  weapon  system  suite  of 
TOs: 
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o  Availability  of  MIL-STD  1840  supporting  DTDs  and  OSs  to  help 
convert  older  paper  TOs  since  the  DTD/OS  focus  is  on  conformance 
of  newly  authored  digital  TOs; 

o  Slow  buildup  of  the  digital  TO  inventory  due  to  economic  consider¬ 
ations  or  technical/operational  problems  with  paper-to-digital  con¬ 
version  or  Data  Type  Definition  (DTD)  specification  conformance; 

o  MIL-STD  1840  compliant  digital  TOs  (from  contractor  authoring 
producers  or  converters)  may  not  be  standardized  enough  and  thus 
may  require  additional  Tier  2  labor  to  support  productive  TO  use 
within  AFTOMS; 

o  Premature  integration  of Type  C  capability  into  AFTOMS  before  its 
unique  support  infrastructure  within  AFTOMS  is  clearly  under¬ 
stood  and  delineated; 

o  The  POC  did  not  establish  whether  a  neutral  database  model  like 
that  needed  to  support  Type  C  TOs  can  be  built  in  time  for  AF¬ 
TOMS  IOC  and  then  operated  successfully  on  a  large  scale; 

o  Inadequate  knowledge  of  the  detailed  interfacing  or  support  re¬ 
quirements  for  PDD  and  Work  Area  TO  delivery  systems  (e.g.,  IMIS 
and  ITDS)  can  impair  future  AFTOMS  interoperability  with  these 
and  other  Tier  4  systems; 

o  Technological  and  economic  risks  of  developing  a  single  integrated 
and  secure  AFTOMS  far  outweigh  the  benefits; 

o  Temptation  may  exist  to  use  a  funded  AFTOMS  program  as  a  ve¬ 
hicle  to  incorporate  additional  CALS  functionality,  thereby  increas¬ 
ing  and  diffusing  the  scope  of  AFTOMS  beyond  TO  management 
and  distribution,  and  jeopardizing  AFTOMS  success; 

o  AFTOMS  buildability  risk  needs  to  be  (and  can  be)  lowered  signifi¬ 
cantly  with  a  quality  set  of  technical  and  operational  requirements  in 
the  RFP,  that  suitably  constrain  any  contractor’s  solution  flexibility 
and  provide  an  unambiguous  basis  for  determining  if  a  proposed 
and/or  implemented  solution  meets  AFTOMS,  MAJCOM,  and 
CALS  long-term  needs; 

o  Failure  to  take  full  advantage  of  the  FY89-FY90  POC  work  (as  de¬ 
lineated  in  this  report)  to  maximize  the  potential  for  total  buildabil¬ 
ity  risk  reduction;  and 

o  Standards  have  gaps  important  to  AFTOMS  e.g.,  Document  Man¬ 
agement  Systems  (DMS)  technology'  products  lack  standards  w'hose 
absence  could  increase  AFTOMS  life  cycle  costs;  and  optical  media 


2-4 


are  not  yet  accepted  by  the  government  as  a  standard  for  permanent 
storage  of  archival  data. 

•  Sixteen  (16),  as  marked,  are  significant  in  severity;  and 

•  Seven  (7),  as  marked,  are  merely  localized  in  significance. 

These  integration  risk  findings  are  summarized  in  Section  4. 

2.3  INTEGRATION  FINDINGS 

Using  a  standardized  format,  TABLE  2-1  summarizes  the  AFTOMS  POC  findings  that  are 

most  relevant  to  each  integration  dimension. 

Each  integration  dimension  in  the  table  consists  of  two  facing  pages: 

•  Left  Hand  Page.  The  page  is  structured  into  the  headings  of  Integration  Di¬ 
mension  and  State  of  Feasibility. 

o  Integration  Dimension.  A  narrow  vertical  panel  on  the  left  side 
identifies  the  topic  and  capsules  its  relevance  to  AFTOMS. 

o  State  of  Feasibility.  Two  vertically  stacked  horizontal  panels  on  the 
right  summarize  the  POC  feasibility'  assessment.  The  upper  panel 
summarizes  the  integration  dimension's  “State  of  Feasibility"  as  it 
exists  in  FY89  during  the  POC  period;  and  the  lower  panel  summa¬ 
rizes  that  integration  dimension’s  forecasted  state  of  practicality  to 
support  the  full-scale  development  and  deployment  of  AFTOMS 
between  FY91-FY93.  Each  state  description  focuses  on  generally 
supported  capabilities  and  significant  deficiencies  important  to  AF¬ 
TOMS.  Whatever  is  feasible  in  FY91-FY93  should  remain  so  be¬ 
yond  FY93,  unless  major  unforeseen  changes  occur.  Consequently, 
only  developments  affecting  the  risk  or  deficiency  areas  need  to  be 
monitored  and  reevaluated  if  AFTOMS  development  is  delayed. 

•  Right  Hand  page.  The  right  hand  page  is  structured  into  the  headings  of  Inte¬ 
gration  Dimension  and  FY91-FY93  Risk. 

o  Integration  Dimension.  A  narrow  vertical  panel  on  the  left  side  re¬ 
peats  the  topic  and  lists  the  symbol  legends  used  to  code  the  signifi¬ 
cance  of  identified  risks. 

o  FY91-FY93  Risk.  Assessments  of  Post-POC  residual  risks  are  sum¬ 
marized  in  the  middle  column.  Then  corresponding  risk  abatement 
recommendations  (wherein  a  strategy  or  approach  is  proposed  for 
each  risk  to  avoid,  minimize,  or  control  it)  are  summarized  in  the 
rightmost  column.  These  recommendations  include  no  specific 
product  mentions. 
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All  the  table  entries  of  content  on  both  facing  pages  are  abstracted  from  the  detailed  integra¬ 
tion  reports  contained  in  Appendix  B;  the  integration  dimensions  in  the  table  are  sequenced 
in  the  same  order  as  in  the  appendix.  These  appendices  should  be  read  to  gain  a  deeper  and 
more  comprehensive  understanding  of  individual  dimensions  of  integration,  assess  their  rele¬ 
vance  to  AFTOMS,  review  important  specific  issues,  and  appreciate  the  context  for  the  POC 
findings. 
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This  page  in  Section  2  is  left  intentionally  blank  to  format  the  following  table  with 
facing  pages. 


TABLE  2-1.  SUMMARY  OF  INTEGRATION  FINDINGS  FOR  AFTOMS 


INTEGRATION 

DIMENSION 


MANAGEMENT 
of  DISTRIBUTED 
USER 

FUNCTIONALITY 


STATE  OF  FEASIBILITY 


RELEVANCE: 


To  gain  maximum 
benefits  from  the 
automation  of 
technical  order 
management, 
AFTOMS  needs  to 
implement  the 
To-Be  concept 
rather  than  merely 
automate  the  As -Is 
functionality. 

Given  the  POC 
work,  this  section 
reassesses  the 
feasibility  of  the 
AFTOMS  To-Be 
model  in  terms  of 
its  tiered  architec¬ 
ture  and  major 
functionality 


FY89: 


This  analysis  shows  that  the  AFTOMS  To-Be  Concept: 

■  Is  internally  consistent; 

■  Can  be  integrated  to  provide  the  major  functionality';  and 

■  Should  satisfy  the  operational  needs  of  the  Air  Force  TO 
community. 

The  Demo  System  work  reinforces  the  quality  and  viability  of  the  concept 
with  respect  to  correctness,  internal  consistency,  and  buildability;  also,  the 
user  interface  prototypes  demonstrated  in  the  Demo  System  appear  to 
match  the  needs  of  all  major  classes  of  users:  data  managers,  maintenance 
technicians,  publications  personnel,  and  operations  personnel.  However, 
being  a  small-scale  prototype  which  incorporates  only  essential  functional¬ 
ity  needed  for  the  POC,  the  Demo  System  did  not  test  usage  conditions 
under  a  realistic  TO  database  load;  a  pilot  system  installed  at  one  ALC 
could  provide  this  capability. 


FY91-FY93: 

Additional  ongoing  work  by  the  AFTOMS  SPO  for  developing  the  detailed 
RFT  requirements  (to  define  carefully  al  t  necessary  levels  of  the  AF¬ 
TOMS  concept)  should  not  degrade  the  i  .cept's  feasibility  provided  its 
core  structure  is  maintained  while  the  supporting  detailed  needs  and  prob¬ 
lems  are  analyzed  relative  to  the  core  structure. 


TABLE  2-1.  SUMMARY  OF  INTEGRATION  FINDINGS  FOR  AFTOMS  (CONT’D) 


INTEGRATION 
DIMENSION 
II  (CONTD) 


MANAGEMENT 
of  DISTRIBUTED 
USER 

FUNCTIONALITY 


LEGEND 

RISK  ASSESSMENT 
SYMBOLS: 

^  HIGH 
MEDIUM 


y  low 


FY91-FY93  RISK 


ASSESSMENT 

Residual  concept-related  risks  are 
present  in  the  following  areas: 

The  operational  ability  to  perform 
Type  A-to-Type  B  document  con¬ 
version  economically  for  a  com¬ 
plete  weapon  system  suite  of  TOs. 


Availability  of  MIL-STD-1840 
supporting  DTDs  and  OSs  to 
help  convert  old  TOs  since  the 
DTO/OS  focus  is  conformance  of 
newly  authored  digital  '1  Os. 


B  Distribution  management  com¬ 
plexity  in  integrating  commodity 
TOs  with  weapon  system  TOs  for 
single  point  distribution  from  TO- 
MAs  to  CTODOs. 


8  Defining  a  "standard”  layered  in¬ 
terface  between  AFTOMS  Tiers 
3&4  which  can  support  multiple 
Tier  4  delivery  systems  (e  g., IMIS, 
ITDS,  etc.) 

DMany  residual  integration  risks 
exist  locally  within  the  sub-levels 
of  the  functionality:  they  are  iden¬ 
tified  in  the  Appendix  B  Sections, 
B1-B8. 


ABATEMENT 

The  Air  Force  could  abate  these 
risks  by: 

□  Instituting  a  pilot  conversion 
activity  on  a  representative  suite 
of  TOs  as  soon  as  possible. 


□  Investigating  this  risk  as  part  of 
the  foregoing  pilot  activity  by  us¬ 
ing  interim  versions  of  DTD/OSs 
if  necessary. 


□  Investigating  this  issue  further. 


□  Investigating  this  issue  further. 

Q  Using  the  POC  findings  and  the 
Demo  System  to: 

■  Solicit  feedback  continuously 
from  potential  AFTOMS  users 
to  refine  &  coordinate  the  con¬ 
cept: 

■  Update  &  extend  the  Demo 
System  to  explore  the  implica¬ 
tions  of  this  feedback: 

■  Use  the  Demo  System  as  a 
training  and  educational  tool 
within  the  AFTOMS  commu¬ 
nity  to  focus  activities  and  in¬ 
crease  development  productiv¬ 
ity;  and 

■  Incorporate  Demo  System  con¬ 
cepts  into  the  System  Opera¬ 
tional  Requirements  Docu¬ 
ment  (SORD)  and  Functional 
Description  (FD)  to  reinforce  a 
coordinated  and  tested  view  of 
AFTOMS  functionality. 
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TABLE  2-1.  SUMMARY  OF  INTEGRATION  FINDINGS  FOR  AFTOMS  (CONT’D) 


INTEGRATION 

DIMENSION 


STATE  OF  FEASIBILITY 


HANDLING  and 
CONVERSION  of 
HETEROGENEOUS 
TECHNICAL 
ORDER  DATA 


RELEVANCE: 

The  entire  growing 
Air  Force  inventory 
of  150,000-plus 
TOs,  whose  type  is 
heterogeneous  and 
content  is  dynam¬ 
ic,  must  be  man¬ 
aged  by  AFTOMS 
over  a  prolonged 
time  period. 

This  section  ex¬ 
amines  this  issue 
by  reviewing  its  3 
major  aspects: 

•  simultaneous 
management  of 
unclassified  TO 
Types  A,  B-,  B, 
B+,  and  C; 

■  conversion  of 
Type  A  paper  and 
contractor  digital 
TOs  to  a  standar¬ 
dized  Type  form; 
and 

*  handling  the 
currently  small, 
but  increasingly 
important  and 
growing  subset 
of  classified  or 
restricted  TOs. 


FY89:  1 

Management  of  Type  A  B-,  B,  and  B  +  IDs  is  readily  integrated  into  the 
AFTOMS  To-Be  model.  Detailed  requirements  for  integrating  Type  C 
support  capabilities  into  AFTOMS  were  not  investigated;  but  full  manage¬ 
ment  of  Type  C  TOs  appears  to  require  AFTOMS  support  in  authoring, 
verification,  change  management,  and  on-line  delivery.  These  capabilities 
appear  challenging  technically  and  operationally,  thereby  adding  to  the 
program  development  workload  in  the  short  term  to  meet  AFTOMS  IOC. 

AFTOMS  is  most  productive  in  managing  standardized  digital  Type  B-/B/ 
B+  TOs;  therefore,  the  economic  conversion  of  Type  A  TOs  to  Types  B- 
or  B  should  be  a  high  near-term  priority  for  the  program.  Current  solu¬ 
tions  are  not  sufficiently  economical  to  handle  the  large  bulk  conversion 
requirements  of  the  Air  Force. 

A  single  integrated  classified  'unclassified  AFTOMS  is  not  now  feasible. 


FY91-FY93: 

Feasibility  of  mixed  inventory  management  is  best  maintained  by  adhering 
to  the  following  practices: 

■  Implement  existing  To-Be  authoring,  distribution,  and  change 
management  concepts  to  reduce  AFTOMS  complexity, 

■  Incorporate  Type  C  concepts  which  are  consistent  with  To-Be 
model  constraints  (e.g.,  reduce  redundancy  during  cataloging,  sim¬ 
plify  view  creation  through  tagging,  allow  only  fixed  views,  etc.); 
and 

■  Accept  new  TOs  in  the  format  (B  or  C)  to  be  managed  and  used, 
thereby  eliminating  unnecessary  conversion  or  repeated  transla¬ 
tion. 

Type  A-to-B  conversion  feasibility  will  increase  significantly  as  the 
emerging,  more  intelligent,  and  automated  conversion  technology  becomes 
installed  and  reduces  the  cost-per-page  significantly. 

Acceptable  trustworthy  and  secure  technology  for  handling  both  classified 
and  unclassified  TOs  in  a  single  integrated  system  still  will  not  be  available 
to  support  the  sophisticated  commercial  software  products  integrated  to 
provide  the  full  AFTOMS  functionality. 


TABLE  2-1.  SUMMARY  OF  INTEGRATION  FINDINGS  FOR  AFTOMS  (CONT’D) 


INTEGRATION 
DIMENSION 
12  (CONTD) 


HANDLING  and 
CONVERSION  of 
HETEROGENEOUS 
TECHNICAL 
ORDER  DATA 


FY91-FY93  RISK 


LEGEND 


RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


ASSESSMENT 


Residual  concept-related  risks  are 
present  in  the  following  areas: 

nThe  POC  did  not  establish 

whether  a  neutral  database  mod¬ 
el  like  that  needed  to  support 
Type  C  TOs  can  be  built  in  time 
for  AFTOMS  IOC  and  then  op¬ 
erated  successfully  on  a  large 
scale. 


Technological  and  economic  risks 
of  developing  a  single  integrated 
and  secure  AFTOMS  far 
outweigh  the  benefits. 


T  A  t'-'-R  ccT'',e'siC'r  viv  :  : 
come  economically  affordable, 
although  technological  limita¬ 
tions  may  prevent  a  full  conver¬ 
sion  to  Type  B;  but  a  subset  of 
Type  B-  TOs  is  manageable. 
Also,  direct  conversion  of  con¬ 
tractor  digital  to  AFTOMS  digi¬ 
tal  may  be  an  alternative  conver¬ 
sion  option  for  some  sets  of  TOs. 


ABATEMENT 


The  Air  Force  could  abate  these 
risks  by: 

l~l  Performing  a  detailed  operation¬ 
al  evaluation  of  the  Type  C  con¬ 
cept  to  establish  the  AFTOMS 
support  requirements.  Recog¬ 
nizing  that  a  minimal  amount  of 
Type  C  data  will  exist  before 
FY2000,  AFTOMS  development 
should  focus  first  on  full  Type  B 
family  management,  followed  by 
incorporation  of  Type  C  support. 
In  the  interim,  as  described  in 
Section  B2.2.2,  Type  B  +  TOs 
provide  the  Tier  4  users  with  sim¬ 
ilar  TO  data  display,  navigation, 
and  cross  referencing  benefits  as 
offered  by  Type  C-  TOs. 

n  Using  a  separate,  physically  se¬ 
cure,  mini-AFTOMS  to  support 
the  classified  TOs  inventory  (less 
than  5%  of  all  Air  Force  TOs 
now)  either  indefinitely  or  until 
practical  technology  is  available 
to  support  an  integrated  ap¬ 
proach.  Scrubbed  classified  TO 
catalog  information  can  still  be 
merged  into  the  unclassified  AF¬ 
TOMS  system. 

O  Not  waiting  until  FY93  to  begin 
the  Type  A-to-Type  B  conversion 
since  early  experimentation  on  a 
pilot  basis  will  provide  a  better 
experience  base  for  planning  the 
full-scale  conversion,  which 
should: 

■  Convert  as  much  of  the  TO 
inventory  as  soon  as  possible 
on  a  weapon  system  and 
commodity  basis  using  service 
bureaus; 

■  Enhance  the  converted  digi¬ 
tal  TOs  to  Type  B  + ;  and 

■  Individually  upgrade  (later  as 
needed)  any  problematic 
Type  B-  TOs  to  Type  B  sta¬ 
tus. 
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TABLE  2-1.  SUMMARY  OF  INTEGRATION  FINDINGS  FOR  AFTOMS  (CONT’D) 


13  INTEGRATION 

DIMENSION 

STATE  OF  FEASIBILITY 

SUPPORT  of 
HETEROGENEOUS 
SYSTEM  USERS 

RELEVANCE: 

Different  classes  of 
users  (managerial, 
technical,  edito¬ 
rial,  production 
and  Tier  4  mainte¬ 
nance)  will  coexist 
and  need  to  be 
supported  by  the 
system.  The  goal 
is  to  make  all  AF¬ 
TOMS  users  more 
productive  through 
quality  require¬ 
ments  definition 
and  system  design. 

This  section 
examines  key  re¬ 
quirements  for 
such  heterogeneous 
user  support,  vari¬ 
ous  user  interface 
design  approaches, 
standards,  and  the 
implications  of 

B+  custom  deliv¬ 
ery  of  TO  informa¬ 
tion  to  Tier  4  us¬ 
ers  in  a  more  use¬ 
ful  form.  In  sum¬ 
mary,  it  explores 
the  feasibility  of 
building  integrated 
user  support. 

FY89: 

Relational  databases  handle  management  and  conventional  data  well. 
Document  management/publishing  systems:  handle  textual/graphical/tabu- 
lar  data  and  TO  configuration  control  well;  and  provide  annotation,  group 
review  and  other  capabilities  useful  for  TO  change  management.  And  hy¬ 
pertext  capabilities  are  needed  for  TO  navigation  at  Tier  4.  None  of  these 
systems  handle  the  others’  data  types  well,  but  AFTOMS  needs  to  inte¬ 
grate  all  three  types  of  data  handling.  The  "software  glue”  that  integrates 
these  disparate  elements  into  a  seamless  AFTOMS  is  consistency  of  user 
interfaces.  In  the  heterogeneous  hardware  and  software  environment  of 
AFTOMS,  feasibility  of  supporting  system  users  is  heavily  dependent  on 
the  emerging  de  facto  X-Windows  standard  and  its  commercial  support, 
which  is  now  inadequate.  The  visible  "look  &  feel”  of  user  interfaces  is 
still  not  standardized;  this  can  be  overcome  if  AFTOMS  incorporates 
graphical  windowing-style  user  interfaces,  not  character-based  ones. 

Use  of  SGML  is  essential  (but  difficult)  for  document  tagging  and  synchro¬ 
nization  of  changes  across  TOs  because  SGML  is  currently  designed  for 
batch  systems,  incorporates  over  350  individual  codes,  and  is  difficult  to 
integrate  internally  into  an  interactively-oriented  system  like  AFTOMS. 

New,  more  flexible,  and  easier-to-use  SGML  products  are  beginning  to 
emerge  so  that  present  difficulties  should  slowly  become  less  problematic. 

Products  for  customized  presentation  of  TO  views,  navigation  within  or 
across  views,  are  just  emerging,  and  will  need  further  development. 

|  FY91-FY93:  f 

Significant  advances  are  expected  in  hardware  and  technology  areas  of  con¬ 
cern  to  AFTOMS:  user  interface  products,  maturing  of  standards,  data 
transparency  in  a  distributed  and  varied  data  type  environment,  on-line 
distribution/display  of  TOs  to  WAs,  groupware  and  conferencing  for  Tier  2 
change  management,  and  technology  integration  tools.  Specifically: 

■  For  user  interfaces,  X-Windows  products  should  be  production 
grade  in  reliability  and  performance,  the  X-protocol  will  be  sup¬ 
ported  by  products  likely  to  be  integrated  into  AFTOMS,  the  "look 
&  feel”  confusion  largely  resolved,  and  programming  graphically- 
based  user  interfaces  made  easier, 

■  Emphasis  will  remain  on  standards-based  open  architecture  sys¬ 
tems  that  are  more  easily  upgraded  technologically; 

■  Tfechniques  for  interactive  SGML  validation  will  appear  and  re¬ 
ceive  widespread  acceptance,  providing  more  powerful  tools  for 
handling  tags  more  productively  and  transparently; 

■  More  integration  will  be  embedded  in  database,  document  man¬ 
agement,  and  on-line  delivery  products  to  handle  more  easily  and 
transparently  the  various  data  types  important  to  AFTOMS  and 
provide  a  better  basis  for  supporting  Type  C  (neutral  data)  TOs; 
and 

■  Tbols  and  integration  capabilities  will  be  available  to  design  AF 
TOMS  to  take  advantage  of  advanced  hardware  likely  to  appear 
after  FY93,  during  the  TOMA/CTODO  installations. 

TABLE  2-1.  SUMMARY  OF  INTEGRATION  FINDINGS  FOR  AFTOMS  (CONT’D) 


INTEGRATION 
DIMENSION 
13  (CONTD) 


SUPPORT  of 
HETEROGENEOUS 
SYSTEM  USERS 


FY91-FY93  RISK 


LEGEND 


RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


LOW 


ASSESSMENT 


Residual  risks  are  present  in  the 
following  areas: 

BTfechnical  integration  of  database, 
document  management,  and  hy¬ 
pertext  on-line  delivery  technol¬ 
ogies  with  their  inherently  differ¬ 
ent  underlying  data  models  to 
support  T^pe  B  digital  and  future 
Type  C  neutral  data. 

B  Current  SGML  models  are  based 
on  structural  rather  than  seman¬ 
tic  analysis,  so  automatic  identifi¬ 
cation  of  related  but  not  identical 
technical  material  (within  the 
same  TO  or  across  TOs)  is  diffi¬ 
cult;  an  operator-assisted  ap¬ 
proach  to  SGML  tagging  of  TOs 
will  be  needed,  adding  some  op¬ 
erational  complexity  and  cost. 

B  Separate  developments/procure¬ 
ments  of  AFTOMS  and  MAJ- 
COM's  Tier  4  TO  delivery  sys¬ 
tems  will  increase  integration 
problems. 

BKey  undecided  operational  re¬ 
quirements  for  system  usage 
(e.g.,  change  management  at  Tier 
2  and  TO  traversal  at  Tier  4)  af¬ 
fect  the  design  of  AFTOMS  in 
broad  and  fundamental  ways. 

B  Possible  requirements  for  imple¬ 
mentation  of  AFTOMS  on  exist¬ 
ing  HW  platforms  (e.g.  z248s) 
will  add  to  design,  implementa¬ 
tion,  and  operational  complexity. 

B  Delivery  of  TO  data  to  WAs  with 
sufficient  flexibility  to  permit  dis¬ 
play  of  information  on  portable 
devices  with  relatively  small 
screens  and  low  amounts  of 
memory  will  add  complexity. 

D  Design  of  consistent,  easy-to-use 
user  interfaces  for  all  classes  of 
AFTOMS  users  will  pose  some 
problems. 


ABATEMENT 


The  Air  Force  could  abate  these 

risks  by: 

□  Simplifying  and  phasing  in  re¬ 
quirements:  a  data  model  suffi¬ 
cient  to  support  B  +  require¬ 
ments  should  be  built,  anticipat¬ 
ing  later  conversion  or  use  of  the 
TO  data  in  a  new,  post-B  +  neu¬ 
tral  model. 

0  There  are  at  least  20  times  as 
many  steps  as  tasks/subsections 
in  TOs.  Therefore,  using  larger 
taggable  units  for  TO  granularity 
(or  lowest  level  of  information  to 
tag  separately)  vastly  simplifies 
SGML  tagging  and  verification 
operationally  and  will  reduce  the 
conversion  cost  of  existing  TOs. 

□  Working  closely  with  Using  Com¬ 
mands  to  define  the  standard  in¬ 
terface  requirements  for  AF¬ 
TOMS  that  they  can  support. 

I~l  Baselining  broad-ranging  process 
decisions  (e.g.,  those  involving 
job  functions,  neutral  data  sup¬ 
port,  interactive  vs.  batch  pub¬ 
lishing,  support  of  existing  equip¬ 
ment,  etc.)  early  for  the  RFP. 

0  Developing  one  version  of  the 
SW  and  user  interfaces  that  will 
run  on  all  (possibly  upgraded) 
HW  platforms  since  reconfigur- 
able  SW  is  usually  problematic. 

[~1  Working  with  Using  Commands 
to  define  such  specialized  display 
requirements;  may  need  to  deliv¬ 
er  TO  data  in  other  than  full- 
page  form. 

0  Using  standardized  protocols  and 
tools  such  as  X-W'indows  and 
whatever  "look  &  feel”  toolkit  is 
widely  supported. 
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TABLE  2-1.  SUMMARY  OF  INTEGRATION  FINDINGS  FOR  AFTOMS  (CONT'D) 


14  INTEGRATION 
DIMENSION 


USE  of 

ELECTRONIC 

COMMUNICATION 

RELEVANCE: 

AFTOMS  will 
require  electronic 
communication  to 
provide  embedded 
transport  and 
routing  functions 
to  support  distri¬ 
bution  of  users, 
hardware,  data, 
and  functionality 
both  within  and 
across  the  tiers. 

This  section 
examines  the  key 
issues  for  defining 
a  communication 
architecture  which 
offers  responsive 
performance  and 
adequate  capacity 
while  appearing  to 
be  transparent  to 
users,  supporting 
heterogeneous 
platforms  and  soft¬ 
ware  systems,  and 
adhering  to  evolv¬ 
ing  government 
communication 
standards. 


STATE  OF  FEASIBILITY 


FY89: _ | 

To  meet  AFTOMS  performance  objectives,  selection  of  communication 
standards  and  vendor  hardware/software  products  for  system  integration 
must  be  directed  with  distributed  rather  than  centralized  operations  in 
mind.  The  supporting,  distributed  AFTOMS  network  architecture  should 
provide  embedded  electronic  data  transport  and  routing  functions,  and  con¬ 
sist  of:  Local  Area  Networks  (LANs)  servicing  intra-tier  requirements;  and 
long-haul  Wide  Area  Networks  (WANs)  providing  paths  between  tiers  or 
remote  sites  within  tiers.  The  primary  types  of  communication  traffic  on 
this  network  will  be  electronic  mail,  file  transfers  of  technical  data,  man¬ 
agement  database  transactions,  and  on-line  conferencing  during  group 
technical  content  reviews.  To  reduce  the  overall  traffic  load,  the  primary 
bulk  distribution  medium  for  TOs  will  be  optical  disk  because  a  typical  TO 
page  (consisting  of  60%  text  and  40%  graphics)  on  average  will  require  30 
Kbytes  of  digital  storage  or  electronic  transfer. 

Other  than  electronic  conferencing  applications  (which  are  now  restricted 
to  a  homogeneous  workstation  population),  hardware  and  software  is  cur¬ 
rently  available  to  support  AFTOMS  communication  requirements  and 
current  DoD  communication  protocols.  Available  LAN  (at  10  Mbps)  and 
high-speed  WAN  (exceeding  56  Kbps)  technologies  support  transaction 
query/  response  times  of  less  than  5  seconds  and  TO  transfer  times  of 


5-to-10  minutes.  To  support  AFTOMS  operationally,  additional  LAN  in¬ 
stallations  and  WAN  connections  will  be  required  in  the  AF. 


The  AF  has  published  new  system  implementation  guidelines,  including  its 
long-range  plans  for  the  Local  Information  Transfer  Architecture  (LJTA) 
and  the  Long  Haul  Information  Transfer  Architecture  (LHITA),  as  part  of 
its  AF  Information  System  (AFIS).  Both  sets  of  guidelines  call  for  transi¬ 
tion  from  current  DoD  protocols  to  Government  Open  Systems  Intercon¬ 
nection  Profile  (GOSIP)  conforming  ones.  GOSIP  will  become  mandatory 
after  August  1990.  AFTOMS  can  comply  by  requiring  strict  adherence  to 
DoD  standards  in  the  near  term  and  following  the  AFIS  migratory  path  in 
the  long  term;  for  example,  selection  of  AFTOMS  communication  equip¬ 
ment  should  be  based  on  Unified  LAN  Architecture  (ULANA/LTTA)  and 
Defense  Data  Network  (DDN/LHTTA)  specifications.  A  reliable,  GOSIP 
compliant  and  DoD  approved  replacement  for  the  current  Transmission 
Control  Protocol  (TCP),  called  TP4,  may  not  be  available  to  support  inter¬ 
net  routing,  reliable  transport,  and  electronic  conferencing,  so  TCP  will 
have  to  be  used  in  the  interim.  If  needed,  DoD  E3  devices  can  provide 
multi-level  security  for  data  transmission  through  the  DDN. 

Data  transfer  rates  are  adequate  to  support  AFTOMS.  If  additional  per¬ 
formance  is  needed  along  specific  links  of  the  AFTOMS  network  architec¬ 
ture,  then  LAN  transmission  rates  of  100  Mbps  are  possible  with  a  Fiber 
Data  Distribution  Interface  (FDDI)  offering  response  tiroes  comparable  to 
disk  access,  and  T1  rates  of  1.544  Mbps  are  available  for  WAN  links. 

Adequate  planning  leadtime  is  needed  to  implement  all  these  links. _ 
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TABLE  2-1.  SUMMARY  OF  INTEGRATION  FINDINGS  FOR  AFTOMS  (CONT’D) 


INTEGRATION 
DIMENSION 
14  (CONTD) 


USE  of 

ELECTRONIC 

COMMUNICATION 


FY91-FY93  RISK 


ASSESSMENT 


Residual  risks  are  present  in  the 
following  areas: 

B  Communications  protocol  selec¬ 
tion  may  not  allow  full  compliance 
with  GOSIP. 


LEGEND 


RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


DDN  resources  may  not  be  avail¬ 
able  for  AFTOMS  wide  area  net¬ 
working. 


AFTOMS  traffic  loads  cannot  be 
carried  by  specified  transmission 
facilities  because  of  improper  siz¬ 
ing  and  protocol  selection,  result¬ 
ing  in  bottlenecks,  delays,  and  un¬ 
reliable  user  service. 


D  Existing  TO  systems  (e.g.,  ATOS) 
may  pose  interoperability  issues 
that  restrict  then  integration  with 
AFTOMS. 


ABATEMENT 


The  Air  Force  could  abate  these 
risks  by: 

D  Selecting  system  vendors  that  of¬ 
fer  full  support  and  upgrade  plans  I 
to  GOSIP  Implement  the  full 
DoD  protocol  suite  (ULAN A  I  &  i 
II  for  LANs  and  DDN/LHITA  for  | 
long  haul)  through  TCP/IP;  this 
will  facilitate  future  upgrades  and 
allow  GOSIP  compliance  except 
for  the  TP4  transport  protocol. 

Use  software  products  that  sup¬ 
port  TCP/EP  with  LAN  and  X.25 
DDN  protocols  which  will  facili¬ 
tate  interoperability  and  support 
DoD  E3  security  devices;  use  of 
Network  File  System  (NFS)  in  ad¬ 
dition  to  the  DoD  suite  is  recom¬ 
mended  for  transparent  file  trans¬ 
fer  among  heterogeneous  systems. 

□  Subscribing  to  the  DDN  requires 
at  least  24  months  of  leadtime  to 
coordinate  their  service  requests 
through  the  AF  Communications 
Command  (AFCC)  for  the  DDN; 
this  application  will  require  a  de¬ 
tailed  quantitative  communica¬ 
tions  usage  study  to  support  it.  Or, 
dial-ups  and  leased  circuits  may 
be  used  to  meet  some  WAN  link 
requirements. 

I~1  During  architectural  planning  and 
design,  model  the  anticipated 
message  characteristics  and  traffic 
loads  between  and  within  the  AF¬ 
TOMS  tiers;  adjust  AFTOMS  de¬ 
sign  as  necessary.  This  traffic  load¬ 
ing  information  is  required  for 
subscription  to  the  DDN  and  can 
define  base-level  LAN  needs. 

Examining  such  systems  to  deter¬ 
mine  their  needed  levels  of  inte¬ 
gration  and  communication  inter¬ 
facing  to  AFTOMS  local  and 
long-haul  services. 
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TABLE  2-1.  SUMMARY  OF  INTEGRATION  FINDINGS  FOR  AFTOMS  (CONT'D) 


15  INTEGRATION 
DIMENSION 

INTERFACE  to 
OTHER  AIR 
FORCE  FUNC¬ 
TIONS/SYSTEMS 

RELEVANCE: 

Long  term,  CALS 
modernization  *111 
require  deployment 
of  several  new  puto- 
raated  systems  for 
managing  and  han¬ 
dling  technical 
data.  AFTOMS, 
dedicated  to  TO 
data,  is  only  the 
first  such  system. 
Interoperability  be¬ 
tween  new  systems 
and  with  existing 
systems  is  an  im¬ 
portant  require¬ 
ment  for  CALS. 

This  section  ex¬ 
amines  how  AF¬ 
TOMS  will  interop¬ 
erate  and  interface 
with:  existing  TO 
systems  like 
LMTOS  and  ATOS; 
varied  contractor 
owned  TO  producer 
systems;  unique 
and  incompatible 
TO  delivery  systems 
at  Tier  4  like  IMIS 
and  ITDS;  and  fu¬ 
ture  CALS  techni¬ 
cal  data  systems 
like  PDD. 


STATE  OF  FEASIBILITY 


CALS  refocuses  the  logistics  modernization  effort  toward  sufficiently  inte¬ 
grating  separate  systems  (whether  already  in  place  or  being  developed  now 
or  in  the  future)  so  that  iv  •»  will  interoperate.  Near-term  emphasis  thru 
the  mid-1990's  is  on  interlacing  systems;  thereafter,  emphasis  will  shift  to¬ 
ward  integration.  Interoperability  must  be  carefully  planned  for  in  every 
new  system  if  the  CALS  goal  is  to  be  achieved.  Several  s,  sterns  and  classes 
of  systems  must  be  considered  for  interoperability  with  AFTOMS. 

For  existing  TO  systems,  it  is  feasible  for  AFTOMS  to: 

■  Replace  and  improve  the  TO  management  functionality  being  pro¬ 
vided  by  the  20-year  old  Logistics  Management  of  Technical  Order 
System  (LMTOS),  also  known  as  G022;  and 

■  Use  the  Automated  Technical  Order  System  (ATOS)  to  pro^Je 
TO  change  processing  on  the  diminishing  set  of  paper  TOs  man¬ 
aged  by  AFTOMS  but  not  yet  convened  to  digital  form. 

For  the  many  different  contractor-owned  producer  systems  that  will  author 
and  deliver  new  TOs  to  AFTOMS,  a  wellAlefined  standardized  receiving 
interface  is  needed  and  feasible  based  on  MIL-STD  1840  and  its  supporting 
sets  of  specifications.  Input  into  AFTOMS  of  converted  TOs  should  satisfy 
the  same  data  interchange  requirement  even  though  this  may  require  fund¬ 
ing  the  considerable  amount  of  trained  labor  needed  to  clean  up  TOs  after 
automatic  conversion  processing.  Then  full  AFTOMS  functionality  can  be 
applied  to  any  digital  TO,  no  matter  what  its  source.  This  standardized 
receiving  interface  is  not  yet  operationally  feasible  because  the  enabling 
technologies  are  just  being  developed  into  usable  products. 

For  interoperability  with  varied  TO  delivery  systems  operating  in  WAs,  a 
standardized  interfacing  approach  is  also  feasible.  The  delivery  require¬ 
ments  for  most  weapon  systems  will  be  met  using  a  single  standard  base- 
level  User  System  that  integrates  with  AFTOMS;  there  is  an  AF  initiative 
to  define,  acquire,  and  deploy  such  a  system.  For  other  weapon  systems 
that  develop  unique  delivery  systems  (e.g.,  IMIS  for  ATF,  and  ITDS  for  the 
B2).  AFTOMS  can  support  a  standardized  output  interface  that  each  can 
adapt  to;  this  standard  interface  is  not  yet  defined. 


Interoperability  of  AFTOMS  with  other  technical  data  systems  (e.g.  PDD) 
is  not  yet  feasible  because  the  interfacing  requirements  are  undefined. 


Normal  progress  in  the  enabling  technologies  should  facilitate  the  technical 
feasibility  of  developing  the  interfaces  needed  to  support  AFTOMS  inter¬ 
operability  with  TO  producers,  TO  users,  end  base-level  technical  data 


systems.  Economic  feasibility,  which  is  less  certain  than  technical  feasibil¬ 
ity,  may  limit  the  usage  level  of  those  standardized  interfaces  (e.g.,  fewer 
paper  TOs  are  converted  because  of  cost).  A  more  tightly  integrated  ap¬ 
proach  that  does  not  rely  on  standardized  layered  interfaces  will  be  less 
feasible.  A  more  informed  feasibility  assessment  requires  detailed  defini- 
tion  of  the  interfacing  requirements  for  each  class  of  interface. _ 
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TABLE  2-1.  SUMMARY  OF  INTEGRATION  FINDINGS  FOR  AFTOMS  (CONT’D) 


INTEGRATION 
DIMENSION 
15  (CONTD) 


INTERFACE  to 
OTHER  AIR 
FORCE  FU;  C- 
TIONS/SYSTEMS 


FY91-FY93  RISK 


LEGEND 

RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


ASSESSMENT 


Residual  risks  are  present  in  the 
following  areas: 

B  Temptation  exists  to  use  a  funded 
AFTOMS  program  as  a  vehicle  to 
incorporate  additional  CALS 
functionality,  thereby  increasing 
and  diffusing  the  scope  of  AF¬ 
TOMS  beyond  TO  management 
and  distribution,  and  jeopardizing 
AFTOMS  success  by. 

■  Delaying  definition  of  stable 
requirements; 

■  Adding  functionality  to  be 
developed;  and 

■  Enlarging  the  AF  community 
that  must  be  coordinated  and 
satisfied  to  complete 
AFTOMS. 

B  Inadequate  knowledge  of  the  de¬ 
tailed  interfacing  or  support  re¬ 
quirements  for  PDD  and  Using 
Command's  TO  delivery  systems 
(e.g.,  IMIS  and  II DS)  can  impair 
future  A  FI  QMS  interoperability 
wi'li  these  and  other  systems. 


ABATEMENT 


The  Air  Force  could  abate  these 
risks  by: 

O  Maintaining  the  present  limited 
and  clear  scope  of  AFTOMS  to 
get  it  developed  and  fielded  suc¬ 
cessfully  as  the  first  CALS  system, 
but  provide  standardized  inter¬ 
faces  and  design  flexibility’  to  sup¬ 
port  interoperability  with  other 
CALS  and  user  technical  data  de¬ 
livery  systems. 


New  digital  TOs  (from  contractor 
authoring  producers  or  conver¬ 
ters)  may  not  be  standardized 
enough  to  support  productive  use 
within  AFTOMS. 


□  Working  with  the  PDD  project  as 
needed  to  ensure  AFTOMS/PDD 
interoperability;  and 

Developing  as  soon  as  possible,  a 
standardized  AFTOMS  interface 
specification  to  MAJCOM  User 
Systems  by 

■  Forming  a  team  comprised  of 
AFTOMS  and  IMIS  person¬ 
nel  to  define  in  detail  the  AF- 
TOMSTM1S  requirements; 

»  Forming  a  team  comprised  of 
AFTOMS  and  I  I  DS  person¬ 
nel  to  define  in  detail  the  AF- 
TOMS-ITDS  requirements; 
and 

■  Working  with  the  team  that  is 
defining  a  base-level  standard 
User  System. 

H  Working  with  all  participating  or¬ 
ganizations  to  solidify  and  opera¬ 
tionally  verily  the  MIL-STD  1840 
interface  details  and  specifications 
for  acceptance  of  TO  data  into 
AFTOMS. 


2- 


TABLE  2-1.  SUMMARY  OF  INTEGRATION  FINDINGS  FOR  AFTOMS  (CONT'D) 


16  INTEGRATION 
DIMENSION 


SYSTEM 

BUILDABILITY 


RELEVANCE: 

System  buildability 
addresses  the  inte¬ 
gration  of  individ¬ 
ual  dimensions 
and  commercial 
technologies  to  the 
task  of  building  a 
high  quality  AF¬ 
TOMS  system  that 
fully  realizes  the 
AF  requirements. 
Since  these  are  not 
vet  available,  the 
AFTOMS  To-Be 
model  is  used  as 
an  interim  surro¬ 
gate  of  the  require¬ 
ments  to  evaluate 
system  buildability. 

This  section  ex¬ 
amines  buildability 
risks  and  develops 
a  framework  for 
modeling  the  proj¬ 
ect  risk,  identifying 
key  risk  contribu¬ 
tors,  evaluating 
the  overall  risk, 
and  finding  oppor¬ 
tunities  for  risk  re¬ 
duction. 


STATE  OF  FEASIBILITY 


FY89: _ j 

A  useful  and  not  overly  complex  framework  was  developed  for  quantita¬ 
tively  modeling  project  risk.  Using  this  framework,  the  total  project  risk 
was: 

■  First  decomposed  into  a  cascading,  tri-level,  hierarchical  set  of 
contributing  risk  factors; 

■  Each  of  these  risk  factors  was  then  judgmental!}'  assessed  and 
weighted  both  for  the  factor’s  importance  to  AFTOMS  and  its 
residual  riskiness;  and 

■  Finally,  all  these  weighted  contributions  were  consolidated  (by- 
working  up  the  hierarchical  decomposition  structure)  into  an  inte¬ 
grated  total  for  the  AFTOMS  project. 

This  framework  captured  risk  factors  arising  from  the  task  (what  is  being 
built),  technologies  and  tools  (to  be  used  in  building  AFTOMS).  project 
resources  and  constraints  (which  limit  project  flexibility),  and  the  teams 
(SPO,  Prime  and  IV&V  contractors)  involved  in  building  AFTOMS.  The 
organizational  risks  associated  with  mapping  specific  AFTOMS  functional¬ 
ity  and  responsibility  to  existing  or  new  Air  Force  elements  were  not  con¬ 
sidered  to  be  within  the  scope  of  the  POC  assessment. 

This  risk  modeling  approach  shows  the  pre-POC  buidability  risk  for  AF¬ 
TOMS  to  be  high,  but  capable  of  being  reduced  significantly 


FY91-FY93: 


This  risk  model  demonstrates  that  the  AFTOMS  buildability  risk  can  be 
reduced  to  an  acceptable  residual  level  m  this  time  frame  by  integrating 
the  POC  findings  and  recommendations  into  the  remaining  phases  of  the 
project,  to: 

■  Improve  the  quality  of  RFP  requirements  and  source  selection 
criteria; 

*  Provide  an  analytical  framework  and  functioning  Demo  System 
for  understanding  development  problems,  evaluating  possible 
solution  alternatives,  assessing  their  risks;  and 

■  Demonstrate  dynamically  and  interactively  key  AFTOMS 
capabilities  and  prototype  user  interfaces  to  interested  parties 
in  the  AFTOMS  and  DoD  communities. 
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INTEGRATION 

DIMENSION 


RELIANCE  on 
CONFORMANCE 
to  STANDARDS 

RELEVANCE: 

AFTOMS  confor¬ 
mance  or  noncon¬ 
formance  to  stan¬ 
dards  can  impact 
development  com¬ 
plexity,  system  per¬ 
formance,  opera¬ 
tional  usefulness 
after  installation, 
and  lifecycle  costs. 
These  costs  arise 
from  post-installa¬ 
tion  maintenance, 
enhancement, 
modification,  and 
upgrading  efforts. 
Each  standard  has 
its  particularly 
unique  mix  of  ad¬ 
vantages  and  dis¬ 
advantages. 

This  section  ex¬ 
amines  general 
considerations 
about  standards, 
defines  a  frame¬ 
work  for  viewing 
the  integration  of 
standards,  evalu¬ 
ates  the  risks  and 
feasibility  of  con¬ 
forming  to  selected 
standards. 


STATE  OF  FEASIBILITY 


De  facto  or  de  jure  standards,  used  properly,  offer  AFTOMS: 

■  A  smaller,  less  complex  integration  burden  overall; 

■  Standardized,  sophisticated,  commercially  available  functionality; 

■  Higher  reliability  and  quality  from  the  outset  using  widely  used 
and  tested  products;  and 

■  Flexibility  for  upgrading  standardized  functionality  and  supporting 
heterogeneity  requirements. 

Reliance  on  standards  also  has  several  potential  disadvantages: 

■  Tendency  to  sacrifice  performance  and  freeze  the  state  of  technol¬ 
ogy  below  the  maximum  level  achievable  with  a  tuned  approach; 

■  Unneeded  overhead  present  in  a  generalized  standard  and  mis¬ 
match  in  functionality  between  requirement  and  that  offered  by 
the  standard; 

■  Potential  for  instability  and  obsolescence  of  any  standard  that’s 
not  widely  supported  by  industry  and  government;  and 

■  Unpredictable  or  negative  interaction  effects  of  integrating  multi¬ 
ple  and  sometimes  conflicting  standards. 

More  than  30  individual  standards  relevant  to  AFTOMS  were  evaluated 
independently  and  for  interoperability  problems.  Not  all  the  key  standards 
(e.g.,  DMS,  ODS,  UIMS)  are  sufficiently  complete  in  definition  or  implem¬ 
ented  in  commercial  technology  products  to  readily  support  an  open  system 
architecture  for  AFTOMS  in  FY89. 

FY91-FY93:  j 

AFTOMS  should  pursue  an  open  architecture  design  approach.  This  open 
approach  argues  that  conformance  to  standards  is  a  sensible  system  devel¬ 
opment  strategy.  It  acknowledges  that  the  traditional  goals  of  using  the 
latest  technology,  maximizing  performance,  minimizing  resource  utilization, 
and  customizing  functionality  to  support  cosmetic  variants  (while  still  im¬ 
portant  to  some  degree)  are  now  outweighed  by  the  long-term  goals  of  op¬ 
erational  and  maintenance  productivities  as  well  as  interoperability  with 
other  present  and  future  systems.  Therefore,  a  long-lifecycle,  heteroge¬ 
neous,  and  user-intensive  system  like  AFTOMS  should  take  advantage  of 
the  benefits  of  particular  standards,  while  neutralizing,  managing,  or  bal¬ 
ancing  associated  problems. 

A  framework  for  integrating  multiple  standards  can  be  used  to  control  their 
disadvantages.  This  framework  organizes  the  individual  standards  by  sub¬ 
ject  and  scope,  characterizes  them  by  compliance  (required  or  optional), 
short-term  benefit  (in  building  or  operating  AFTOMSX  long-term  benefit 
(for  maintenance  or  integration),  and  comments  regarding  maturity  level 
and  potential  integration  or  interaction  problems.  The  analysis  shows  that 
an  open  system  architecture  is  largely  feasible  for  AFTOMS  in  this  time 
period  as  progress  in  standards  development  and  their  partial  or  total  sup¬ 
port  in  commercial  products  matures.  However,  some  selective  tradeoffs 
and  workarounds  will  still  be  needed  to  manage  the  residual  risks. 
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INTEGRATION 

DIMENSION 


OPERATIONAL 

UTILITY 


RELEVANCE: 

The  focus  of  opera¬ 
tional  utility  is  ac¬ 
tual  use  of  AF¬ 
TOMS  after  it  is 
built;  specifically, 
how  can  AFTOMS: 
realize  its  automa¬ 
tion  benefits  as 
quickly  as  possible 
after  IOC;  become 
more  productive  in 
day-to-day  opera¬ 
tional  use;  and 
support  future  en¬ 
hancements  and 
integration  with 
other  TO  or  tech¬ 
nical  data  systems 
that  emerge  from 
CALS. 

This  section  ex¬ 
amines  managerial 
and  technological 
approaches  for  in¬ 
creasing  operation¬ 
al  utility  by:  accel¬ 
erating  startup  ac¬ 
tivities,  promoting 
productive  daily 
use,  and  support¬ 
ing  long-term 
effectiveness  of 
AFTOMS. 


STATE  OF  FEASIBILITY 


AFTOMS  will  operate  most  optimally  and  maximize  its  automation  bene¬ 
fits  in  a  fully  digital  TO  environment.  Therefore,  its  operational  utility  is 
enhanced  through  any  measures  that  accelerate  the  transition  and  prog¬ 
ress  toward  a  fully  digital  environment.  Such  measures  include: 

■  Intelligent  system  packaging  and  rapid  installation  of  TOMAs 
using  a  weapon  system  configuration  planning  tool  which  defines 
the  AFTOMS  resources  (equipment,  functionalities,  capacities, 
staffing)  needed  to  support  the  weapon  system’s  TO  goals  &  plans; 

■  Paper-to-digital  conversion  of  existing  TOs  and  B+  tagging  of 
digital  TOs  to  provide  superior  information  customization  and 
control  to  individual  Work  Area  users;  and 

■  Adequate  staffing,  communications  and  training  support. 

Measures  that  provide  productive  daily  use  include: 

■  Incorporating  an  integrated  service  quality  monitoring  program; 

■  Enhancing  TO  database  quality  and  capacity  incrementally  through 
added  levels  of  B  +  tagging  and  a  distributed  system  architecture; 

■  Building  in  practical  functionality  which  provides  operational 
simplicity,  error  recovery,  predictable  performance,  and  confidence 
that  the  user  is  in  control;  and 

■  Periodic  training. 

Measures  that  promote  long-term  effectiveness  and  viability  include: 

■  Flexible  design,  intelligent  integration,  and  interfacing  with  other 
systems;  and 

■  Reliance  on  standards  in  support  of  an  open  architecture  approach. 

All  these  measures  are  technically  feasible  in  FY89;  however,  conversion 
and  B  +  tagging  (both  being  labor  intensive  even  though  partially  auto¬ 
mated)  are  not  yet  economical  on  a  large  scale.  Integration  requirements 
for  support  of  MAJCOM  Work  Area  user  systems  and  other  CALS  systems 
iarenotdefine^uffirientIv2^sses^heiMmpac^i^nerationaMitilitv^^^ 

FY91-FY93:  | 

Per  page  unit  costs  for  conversion  and  B  +  tagging  will  decrease  as  more 
intelligent  and  sophisticated  technology  products  running  on  faster  hard¬ 
ware  platforms  become  available  and  reduce  the  needed  labor  time. 

As  the  integration  and  interfacing  requirements  for  other  TO  and  CALS 
systems  become  defined,  the  feasibility  in  this  timeframe  should  be  en¬ 
hanced  unless  the  requirements  are  extraordinary.  Other  measures  noted 
above  are  feasible  to  define,  plan,  develop,  and  implement  successfully. 

If  adequate  organic  staffing  for  AFTOMS  becomes  a  problem,  then  the  Air 
Force  can  turn  to  service  contractors  to  operate  the  non-critical  portions  of 
AFTOMS  without  compromising  performance  or  delaying  periodic  technol- 
ogy  upgrades. 
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TABLE  2-1.  SUMMARY  OF  INTEGRATION  FINDINGS  FOR  AFTOMS  (CONT’D) 


SECTION  3:  TECHNICAL  ASSESSMENT  OF 
INDIVIDUAL  TECHNOLOGIES: 
OVERVIEW 


3.1  INTRODUCTION 

Technologies,  which  include  software,  hardware,  and  standards  representation,  are  critically 
important  to  AFTOMS.  First,  because  the  overall  functionality  required  to  implement  the 
AFTOMS  concept  is  so  wide  ranging,  with  key  aspects  of  that  functionality  at  or  near  state  of 
the  art  for  available  Commercial  Off-The-Shelf  Software  (COTS)  products.  Then,  given  the 
broad  scope,  range  of  expertise  required,  and  the  ambitious  FY91-FY93  schedule,  it  is  not 
feasible  to  develop  a  customized  version  of  such  functionality,  even  if  it  made  sense  to  do  so. 
For  reasons  of  long-term  cost,  upgradeability,  maintainability,  and  interoperability  with  fu¬ 
ture  CALS  systems,  the  most  effective  strategy  for  AFTOMS  is  to  limit  customized  develop¬ 
ment  to  providing  needed: 

•  Unique  functionality  not  available  in  those  COTS  products  which  support  an 
open  system  architecture;  and 

•  Software  linkages  to  integrate  the  purchased  COTS  technology  products  into  a 
single  seamless  AFTOMS  system. 

3.2  TECHNOLOGY  RISK 

The  technology  risk  is  described  below  by  identifying  the  areas  of  technology  explored  in  the 
POC,  the  approach  used  for  evaluation  of  the  risks  in  each  technology  area,  and  a  capsule 
numeric  summary  of  the  overall  technology  risk  facing  AFTOMS. 

3.2.1  Areas  of  Technology 

Sixteen  areas  of  technology  have  been  identified  as  relevant  to  AFTOMS,  either  in  the  short 
or  long  term: 

•  Object-Oriented  Data  Management  (OODM).  Focuses  on  a  promising,  newly 
emerging  technology  that  integrates  the  management  of  a  wide  diversity  of  sim¬ 
ple  and  compound  data  objects  including  data  items,  text,  graphics,  tables,  au¬ 
dio,  video,  etc.; 

•  Technical  Publishing:  Document  Management  Systems  (DMS).  Focuses  on  a 
rapidly  evolving  technology  that  integrates  large-document  technical  publish¬ 
ing  capabilities  for  group  authoring,  change  and  version  control,  annotation, 
variant  documents,  SGML  tagging,  archiving,  document  history  auditing,  tex- 
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tual/graphical/&tabular  data  input,  layout  control,  composition,  and  all  other 
standard  word  processing  functions; 

•  Distributed  Relational  DataBase  Management  Systems  (RDBMS).  Focuses 
on  an  evolving  technology  that  distributes  established  RDBMS  data  manage¬ 
ment  capabilities  (e.g.,  offering  efficient  data  access  structures,  a  hardware-in- 
dependent  logical  basis  for  formulating  queries  to  retrieve  desired  data  combi¬ 
nations,  etc.)  over  LANs  or  WANs  to  provide  partitioning  of  databases  and 
transparent  data  access  throughout  the  network,  and  to  support  heterogeneous 
hardware  platforms; 

•  User  Interface  Management  Systems  (UIMS).  Focuses  on  making  AFTOMS 
users  more  productive  through  intelligent  design  and  implementation  of  user 
interfaces  that  represent  AFTOMS  to  users,  and  assesses  the  capabilities  of 
this  technology  for  building  and  modifying  the  various  types  of  hardware -inde¬ 
pendent  user  interfaces  needed  in  AFTOMS; 

•  On-Line  Delivery  Systems  (ODS).  Focuses  on  improving  the  productivity  of 
Tier  4  maintenance  technicians  through  effective  use  of  hypertext-tagged  TOs 
with  such  advanced  capabilities  as:  TO  views  customized  for  task/configura- 
tion/and  experience  level,  graphical  zoom  and  rotation  manipulation  that  fo¬ 
cuses  on  specific  data,  branching/referencing  links  to  quickly  navigate  relevant 
portions  of  the  data,  etc.; 

•  Local  Area  Communications.  Focuses  on  the  electronic  transfer  of  digital  in¬ 
formation  within  work  groups,  departments,  buildings,  and  bases  using  Local 
Area  Network  (LAN)  technology,  and  assesses  LAN  technology,  its  standard¬ 
ization  and  ability  to  support  hardware  heterogeneity  and  the  intra-tier  and 
intra-base  distribution  of  AFTOMS  functionality, 

•  Wide  Area  Communications.  Focuses  on  the  long  haul  transfer  of  selected  dig¬ 
ital  information  between  AFTOMS  tiers  and  to  external  contractors,  and  as¬ 
sesses  several  WAN-related  issues  for  AFTOMS  suitable  communication  tech¬ 
nologies.  Based  on  the  POC  scope  and  the  co-location  of  its  equipment  suite, 
WAN  data  transfer  was  not  included  in  the  Demo  System; 

•  Optica]  Disk.  Focuses  on  a  convenient,  high  capacity,  inexpensive,  portable, 
and  stable  data  storage  and  data  transfer  medium  both  for  repositing  TOs  and 
TO-associated  data  at  Tier  2,  and  bulk  distributing  digitally  encoded  weapon 
system  TO  document  suites  from  TOMAs  to  CTODOs; 

•  Demand  Printing.  Focuses  on  selective  printing  (in  CTODOs  or  Tier  4  Work 
Areas)  of  specific  TOs,  pages  within  a  TO,  or  other  TO-associated  and  man¬ 
agement  data;  and  the  key  technology  that  allows  this  flexibility,  demand  print¬ 
ing; 
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•  Workstation  Platforms.  Focuses  on  high-performance,  bit-mapped  graphic 
workstations  as  a  key  technology  for  processing  TOs  (which  requires  integrated 
display  and  processing  of  text  and  graphics  as  well  as  authoring,  tagging,  change 
processing,  and  verifying  TOs),  and  for  support  of  X-window  based  graphical 
user  interfaces  (needed  to  integrate  diverse  technology  products,  make  AF- 
TOMS  able  to  run  on  heterogeneous  HW  platforms  and  easier  to  use  via  con¬ 
sistent  user  interfaces); 

•  DocumentB+  Enhancements.  Focuses  on  B  4-  extensions  to  Type  B  TOs  (de¬ 
fined  in  a  general  sense,  as  those  extensions  that  provide  all  the  TO-related 
functionality  envisioned  for  a  Type  C  system,  except  storage  of  data  in  neutral 
form),  and  assesses  possible  B  +  capabilities,  their  relationship  to  a  future  Type 
C  approach,  and  technologies  needed  to  provide  B+  functionality; 

•  Software  Design/Implementation  Languages.  Focuses  on  software  design  and 
implementation  language  issues  to  successfully  accomplish  a  seamless  integra¬ 
tion  of  several  large-scale,  commercially-developed,  state-of-the-art  systems 
(that  individually  exploit  particular  technologies  and  focus  on  specific  areas  of 
functionality)  into  a  productive  AFTOMS  system;  and  provide  the  necessary 
design  flexibility  to  support  long-term  objectives  of  lower  lifecycle  costs  for 
AFTOMS  and  CALS  interoperability; 

•  Government  Data  Interchange  Standards.  Focuses  on  the  technology  needed 
to  implement  the  automated  solutions  for  the  standard  input-side  interface  to 
AFTOMS,  based  on  MEU-STD-1840.  This  standard  is  the  only  interface  be¬ 
tween  TO  creation  (primarily  performed  by  contractors)  and  TO  management 
performed  in  the  Air  Force  by  AFLC/MM.  It  brings  standardization,  consis¬ 
tency,  and  discipline  to  both  the  TO  product  and  the  management  processes; 
without  its  successful  implementation  AFTOMS  cannot  succeed; 

•  De  facto  and  De  jure  Computer  Industry  Standards.  Focuses  on  a  basis  for 
identifying  and  understanding  AFTOMS-relevant  computer  industry  stan¬ 
dards  (their  scope,  current  state,  interdependence  with  other  standards,  and 
likely  evolution);  the  choice  of  standards  and  their  implementation  significant¬ 
ly  affects:  ease  of  integration  during  development  and  better  quality  and  cost  of 
subsequent  maintenance  (which  includes  correcting  problems,  enhancing  ex¬ 
isting  or  adding  new  functionality,  avoiding  obsolescence,  and  upgrading  op¬ 
erational  performance); 

•  Training  Technologies  and  AFTOMS  Assimilation.  Focuses  on  recent  major 
advancements  in  training  technologies  which  can  benefit  AFTOMS  (in  terms 
of  reduced  training  time,  fewer  required  training  resources,  increased  trainee 
achievement,  lower  attrition  rates,  and  increased  job  proficiency),  and  in  par- 
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ticular,  assesses  the  relevance  of  two  major  areas  of  training:  HW-SW  training 
technology  and  its  underlying  training  methodology.  No  specific  training  prod¬ 
ucts  were  incorporated  into  the  Demo  System;  and 

•  Document  Scanning  and  Conversion.  Focuses  on  the  key  technological,  op¬ 
erational,  and  economical  issues  associated  with  conversion  of  the  large  Air 
Force  paper  TO  inventory  because:  AFTOMS  is  most  effective  in  handling  dig¬ 
ital  TOs;  management  of  TOs  is  a  recurring  operational  cost  which  is  reduced 
when  TOs  are  in  digital  form;  TOs  are  used  for  many  years  (e.g.,  20-30  years) 
and  are  changed  and  reissued  many  times  during  their  life  cycle,  a  dynamic  pro¬ 
cess  which  is  better  controlled  and  facilitated  through  automation;  and  TO 
conversion  represents  a  large,  but  one-time  non-recurring  cost. 

In  most  of  these  technology  areas  vendors  have  invested  highly  specialized,  not  easily  ac¬ 
quired  expertise  and  tens-to-hundreds  of  years  of  professional  effort  to  develop  and  refine 
their  products.  Many  of  these  products  have  benefited  tremendously  from  extensive  usage  in 
varied  operational  circumstances.  This  has  resulted  in  valuable  feedback  that  has  been  used 
to  correct  errors,  add  new  functionality,  smooth  out  rough  edges,  and  generally  make  the 
products  operationally  useful.  Moreover,  given  the  dynamic  nature  of  these  technologies, 
vendors  continue  to  enhance  and  improve  their  products  to  stay  competitive  and  to  make 
their  products  work  in  a  wider  variety  of  circumstances  and  configurations.  These  are 
strengths  that  AFTOMS  can  exploit;  they  provide  leverage  for  developing  a  quality  system 
sooner  as  well  as  maintaining  and  refining  its  quality  longer. 

3.2.2  Risk  Evaluation 

Within  each  technology,  risk  can  arise  in  several  areas,  such  as: 

•  Functionality.  The  technology  does  not  provide  the  specific  functionality  need¬ 
ed  in  AFTOMS  (which  then  has  to  be  custom  developed)  or  the  technology  in¬ 
corporates  excess  functionality  that  is  problematic  (e.g.,  not  needed  in  AF¬ 
TOMS,  difficult  to  deactivate  or  isolate  from  the  desired  functionality,  and  ac¬ 
tually  or  potentially  troublesome  for  the  design  or  operation  of  AFTOMS); 

•  Performance.  The  technology  is  too  limited  or  immature  in  its  multi-year  de¬ 
velopment  cycle  to  provide  adequate  performance  for  supporting  the  antici¬ 
pated  AFTOMS  operational  environment  (e.g.,  capacity,  transaction  rate, 
overhead  processing  burden,  reliability,  error  recovery,  ease  of  use,  etc.); 

•  Compatibility.  The  technology  has  severe  incompatibility  restrictions  on  its 
use  in  an  integrated  system  solution  such  as  AFTOMS  (e.g.,  doesn’t  support 
needed  hardware  platforms,  operating  systems,  or  other  software  products  be¬ 
ing  integrated,  etc.); 

•  Standards.  The  technology  is  short-lived  or  dead-ended  for  use  in  the  open 
system  architecture  design  approach  proposed  for  AFTOMS  since  the  technol- 
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ogy  adheres  to:  no  standards  (is  highly  customized  and  insular);  unpredictable 
or  highlyjcontentious  standards;  or  inappropriate  standards  for  AFTOMS;  and 

•  Viability.  The  technology  will  not  be  widely  commercialized  in  product  form 
(i.e.,  little  demand  for  it,  few  suppliers,  products  not  well  supported,  and  lim¬ 
ited  commercial  interest  for  future  development)  or  the  technology  is  likely  to 
be  displaced  (thus  limiting  its  long-term  usefulness  for  AFTOMS)  by  a  better, 
emerging,  or  established  alternative  technology. 

Each  identified  technology  area  was  evaluated  for  its  degree  of  integration  risk  relative  to  the 
particular  needs  and  special  characteristics  of  the  AFTOMS  concept.  Evaluations  were  per¬ 
formed  for  two  time  frames: 


•  FY89.  to  determine  its  current  feasibility  and  problems;  and 

•  FY91-FY93.  to  forecast  its  feasibility  and  risk  for  the  actual  development  and 
subsequent  use  of  AFTOMS. 

Risks  were  assessed  for  significance  using  the  following  judgmental  scale: 

•  High  Characterizes  those  risks  of  wide-ranging  impact  which  can  significantly 
reduce  automation  benefits  or  jeopardize  AFTOMS  success; 

•  Medium.  Characterizes  those  risks  which  can  compromise  important  auto¬ 
mated  functionality  (relative  to  the  To-Be  system  concept)  and  degrade  pro¬ 
ductivity  somewhat,  yet  not  jeopardize  either  the  automation  benefits  or  pro¬ 
gram  success;  and 

•  Low.  Characterizes  those  risks  which  have  small,  limited  impacts,  and  for 
which  solutions  will  be  defined  during  the  normal  development  process. 

3.2.3  Summai7 

The  59  technolog)'  risks  (or  classes  of  risks)  identified  during  the  POC  for  AFTOMS  are 

listed  in  TABLE  3-1  as  are  corresponding  suggested  approaches  for  abating  them.  Of  these 


•  None  prevent  AFTOMS  from  being  developed  if  the  abatement  recommenda¬ 
tion  is  followed; 

•  Seven  (7)  are  very  significant  in  severity: 

o  OODM  technology  provides  inadequate  support  of  distributed, 
multiuser  systems  that  must  run  on  heterogeneous  hardware  plat¬ 
forms; 

o  Maintaining  data  consistency  and  integrity  is  problematic  if  hetero¬ 
geneous  RDBMS  products  are  networked  in  a  distributed  and  inte¬ 
grated  CALS  architecture; 
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o  Selection  of  the  main  underlying  data  model  for  AFTOMS  must 
provide  for  Type  B,  Type  B  + ,  and  Type  C  support,  or  several  data 
models  must  be  very  carefully  integrated; 

o  Availability  of  verified  DTDs,  Output  Specs  (OSs),  and  thorough 
testing  of  the  MIL-STD 1840  interface  are  critical  to  AFTOMS  suc¬ 
cess  since  major  AFTOMS  components  and  TO  contractors  rely  on 
the  integrity  of  this  interface; 

o  Large-scale  TO  conversion  not  sufficiently  accurate  in  scanning,  re¬ 
quiring  costly  manual  labor  for  post-scan  checking  and  cleanup, 
thereby  reducing  the  number  of  converted  TOs  and  AFTOMS  auto¬ 
mation  benefits; 

o  Large-scale  TO  conversion  not  sufficiently  integrated  as  an  entire 
multi-step  process,  requiring  costly  manual  labor  to  provide  link¬ 
ages  and  data  adjusting  between  individual  processing  steps,  thereby 
reducing  the  number  of  converted  TOs  and  AFTOMS  automation 
benefits;  and 

o  Large-scale  TO  conversion  not  readily  adaptable  to  old  TOs,  re¬ 
quiring  costly  manual  labor  to  retrofit  old  documents  to  new  stan¬ 
dardized  and  MIL-STD  1840  compliant  DTDs  and  OSs,  thereby  re¬ 
ducing  the  number  of  converted  TOs  and  AFTOMS  automation 
benefits. 

•  Thirty  (30),  as  marked,  are  significant  in  severity,  and 

•  TWenty-two  (22),  as  marked,  are  merely  localized  in  significance. 

These  technology  risk  findings  are  summarized  in  Section  4. 

3.3  TECHNOLOGY  FINDINGS 

Using  a  standardized  format,  TABLE  3-1  summarizes  the  significant  AFTOMS  POC  findings 

that  are  most  relevant  to  each  area  of  technology. 

Each  area  of  technology  in  the  table  consists  of  two  facing  pages: 

•  Left  Hand  Page.  The  page  is  structured  into  the  headings  of  Individual  Tech¬ 
nology  and  State  of  the  Technology. 

o  Individual  Technology.  A  narrow  vertical  panel  on  the  left  side  iden¬ 
tifies  the  technology  and  capsules  its  relevance  to  AFTOMS. 

o  State  of  the  Technology  .  Two  vertically  stacked  horizontal  panels  on 
the  right  summarize  the  POC  feasibility  assessment.  The  upper  pan¬ 
el  summarizes  the  “State  of  the  Technology"  as  it  exists  in  FY89  dur- 
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ing  the  POC  period,  and  the  lower  panel  the  forecasted  state  of  prac¬ 
ticality  to  support  the  full-scale  development  of  AFTOMS  between 
FY91-FY93  or  its  subsequent  deployment  Each  state  description 
focuses  on  generally  supported  capabilities  and  significant  deficien¬ 
cies  important  to  AFTOMS;  it  mentions  no  specific  products.  What¬ 
ever  is  feasible  in  FY91-FY93  should  remain  so  beyond  FY93,  un¬ 
less  major  unforeseen  changes  occur.  Consequently,  only  develop¬ 
ments  affecting  the  risk  or  deficiency  areas  need  to  be  monitored 
and  reevaluated  if  AFTOMS  development  is  delayed. 

•  Right  Hand  page.  The  right  hand  page  is  structured  into  the  headings  of  Indi¬ 
vidual  Technology  and  FY91-FY93  Risk. 

o  Individual  Technology.  A  narrow  vertical  panel  on  the  left  side  re¬ 
peats  the  topic  and  lists  the  symbol  legends  used  to  code  the  signifi¬ 
cance  of  identified  risks. 

o  FY91-FY93  Risk.  Assessments  of  Post-POC  residual  risks  are  sum¬ 
marized  in  the  middle  column.  Then  corresponding  risk  abatement 
recommendations  (wherein  a  strategy  or  approach  is  proposed  for 
each  risk  to  avoid,  minimize,  or  control  it)  are  summarized  in  the 
rightmost  column.  These  recommendations  include  no  specific 
product  mentions. 

All  the  table  entries  of  content  on  both  facing  pages  are  abstracted  from  the  detailed  technol¬ 
ogy  reports  contained  in  Appendix  B  of  the  Supplement  to  the  Technology  Issues  &  Alterna¬ 
tives  Report.  This  Supplement  is  a  draft  document  for  AFTOMS  SPO  use  only  since  it  con¬ 
tains  material  not  suitable  for  general  distribution. 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS 


T1  INDIVIDUAL 

TECHNOLOGY 


OBJECT- 
ORIENTED  DATA 
MANAGEMENT 
(OODM) 

RELEVANCE: 

AFTOMS  needs  to 
store  and  manage 
a  variety  of  com¬ 
plex  daia  types. 
OODM  is  a  prom¬ 
ising.  newly  emerg¬ 
ing  technology  that 
(in  an  integrated 
manner)  can  store, 
retrieve,  and  man¬ 
age  both  simple 
data  and  diverse 
compound  data 
objects  (e.g.,  text, 
graphics,  tables,  au¬ 
dio.  video,  etc.). 
Without  OODM, 
AFTOMS  must 
integrate  at  least 
three  data  models: 
RDBMS,  DMS, 
and  ODS. 

Given  the  POC 
work,  this  section 
assesses  the 
OODM  concept 
and  its  suitability 
and  feasibility  for 
pic.iding  inte¬ 
grated  data  man¬ 
agement  support  to 
AFTOMS. 


STATE  OF  THE  TECHNOLOGY 


Conceptually,  OODM  is  very  appealing,  but  in  currently  available  OODM 
products,  basic  limitations  important  to  AFTOMS  east  in: 

■  Optimization  of  object-oriented  queries; 

■  Methods  of  version  control; 

■  Limited  standardization  of  capabilities  across  products; 

■  Integrity  of  constraints  checking,  and  updating  of  multiple  views 
when  data  is  modified; 

■  Partitioning  of  databases  across  distributed,  heterogeneous 
platforms;  and 

■  Ability  to  handle  replicated  data  objects  and  maintain  database 
integrity  and  consistency. 

Also  currently,  there  are  development  and  performance  penalties  to  pay  in 
using  the  few  available  OODM  products: 

■  Longer  technology  learning  curve,  design  time,  and  more  complex 
im,  lementation; 

■  Increased  dependence  on  documentation  and  development  tools, 
which  are  still  immature;  and 

■  Performance  degradation  from  dynamic  binding  of  objects  during 
runiime. 


Not  likely  teat  a  genera.' -purpose  OODM  product  suitable  for  large-scale, 
distributed  systems  operating  on  heterogeneous  platforms  will  be 
operationally  ready  to  satisfy  .AFTOMS’  needs. 


OODM  technology  is  not  a  necessity  for  AFTOMS  success  as  an  advanced 
DMS  or  an  AFPOMS-integrated  DMS'RDBMS'ODS  combination  will 
provide  all  the  teeded  data  storage  and  management  capabilities.  In  fact, 
DMS  technology  is  evolving  to  better  integrate  distributed  RDBMS  and 
ODS  capabilities. 

.As  technology  matures,  complementary  tools  for  working  together  with 
OODM  products  and  object-oriented  languages  will  appear  languages  will 
continue  to  emphasize  processing,  complex  structuring,  and  local  data  capa¬ 
bilities,  whereas,  OODMs  will  emphasize  large  databases  of  varied  and 
shared  data  outside  the  application. 

Except  for  specialized  new  applications,  transition  in  database  usage  from 
RDBMS  to  OODM  is  likely  to  be  slow  because  of  the  high  cost  of  redesign 
and  implementation  to  take  advantage  of  the  object-oriented  approach. 
This  vtll  constrain  the  rates  of  OODM  market  growth  and  product  matura¬ 
tion  for  several  years. 


TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


INDIVIDUAL 
TECHNOLOGY 
T1  (CONT’D) 


OBJECT- 
ORIENTED  DATA 
MANAGEMENT 
(OODM ) 


FY91-FY93  RISK 


ASSESSMENT 


An  effort  to  incorporate  OODM 
technologj  into  AFTOMS  present* 
serious  residual  risks  in  the 
following  areas: 

D  Inadequate  support  of  distributed, 
multiuser  systems  that  must  run 
on  heterogeneous  hardware 
platforms. 


Uncertainty  about  the  effective¬ 
ness  of  object-oriented  query 
optimization  techniques  and  the 
impact  of  the  runtime  overhead 
of  dynamic  binding  on  resulting 
OODM  performance. 


Limited  standardization  of  core 
OODM  capabilities  across  prod¬ 
ucts  and  adherence  to  govern¬ 
ment  or  de  facto  standards. 


Limited  commercial  presence  in 
terms  of  installed  customer  base 
and  number  of  operationa’ly 
mature  products. 


LEGEND 

RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


ABATEMENT 


The  Air  Force  could  abate  these 
risks  by: 


Not  using  early  generation 
OODM  products.  The  AFTOMS 
data  management  requirements 
can  be  addressed  by  DMS  vendors 
using  an  RDBMS  possibly  en¬ 
hanced  with  embedded,  carefully 
optimized,  limited-purpose 
object-oriented  capabilities  (i.e., 
for  textual ''graphical  'tabular  data 
but  not  for  audio,  video,  etc.). 
Therefore: 

•  Monitor  the  development 
progress  of  OODM  systems 
to  assess  their  value  as  a  po¬ 
tential  technology  upgrade  for 
AFTOMS; 

■  Review  new  versions  of  DMS 
and  RDBMS  systems  for  in¬ 
corporation  of  selected 
object-oriented  techniques 
and  characteristics;  and 

■  Use  an  object-oriented  design 
approach  for  AFTOMS  and 
implement  AFTOMS  (wher¬ 
ever  feasible)  in  modular 
fashion  to  provide  flexibility 
for  upgrading  modules  or  sub¬ 
systems  with  new  technology 
once  the  technology  matures 
(provided  the  new  technology 
offers  practical  operational 
benefits  which  can  be  eva¬ 
luated  in  a  pilot  environ¬ 
ment). 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT'D) 


T2  INDIVIDUAL 
_ TECHNOLOGY 

TECHNICAL 
PUBLISHING: 
DOCUMENT 
MANAGEMENT 
SYSTEMS  (DMS) 

RELEVANCE: 

TOs  art  large, 
technicaliv  com¬ 
plex,  updatable 
documents  whose 
contents  have  to  be 
managed  over  long 
time  periods. 

DMS  technology, 
introduced  in  1987, 
offers  all  the  stan¬ 
dard  publishing 
functions  and  the 
most  advanced 
large-document 
technical  publish¬ 
ing  capabilities, 
including:  group 
authoring,  change 
&  version  control, 
annotation,  vari¬ 
ant  documents, 
SGML  tagging, 
archiring,  docu¬ 
ment  history  audit¬ 
ing,  and  textual/ 
graphical/tabular 
data  input. 

Given  the  POC 
work,  this  section 
assesses  the  practi¬ 
cality  of  using 
DMS  technology  in 
AFTOMS. 


STATE  OF  THE  TECHNOLOGY 


DMS  is  a  new  technology  that  integrates  key  elements  of  established  tech¬ 
nologies,  and  which  is  being  expanded  further  to  extend  its  integration  to 
include  RDBMS  and  even  ODS  capabilities. 

Although  there  is  extensive  core  functionality  that  in  some  form  is  common 
to  most  or  all  DMS  vendors  (e.g.,  the  types  of  text  manipulation  supported 
by  publishing  software,  WYSIWYG  processing,  annotation  features,  support 
of  laser  printer  and  typesetter  output  devices,  etc.),  there  are  also  major 
proprietary  differences  among  DMS  products  in  hardware  platforms  sup¬ 
ported,  change  control  management  functionality,  file  &  data  formats,  and 
workflow  management. 

M1L-STD  1840  compliance  of  DMS-authored  documents  is  still  not  fully 
verified  although  no  critical  problems  are  foreseen.  SGML  processing 
support  is  beginning  to  be  integrated  into  DMS  products,  but  is  not  yet  user 
friendly. 

Given  the  additional  functionality  and  power  that  is  incorporated  in  DMS 
technology  (and  needed  for  TOs),  somewhat  more  training  is  required  with 
DMS  products  than  with  word  processing  products  for  effective  document 
authoring. 


DMS  is  a  rapidly  maturing  technology  whose  further  development  is  being 
focused  and  stimulated  by  CALS  requirements  as  follows: 

•  Major  products  should  all  support  distributed  heterogeneous 
platforms  once  they  are  ported  to  X-window  &  UNIX,  thereby 
eliminating  proprietary  hardware  issues; 

■  Integration  of  RDBMS  or  a  Limited  object-oriented  data  manage¬ 
ment  capability  into  DMS  will  better  support  the  management  of 
document  authoring,  editing,  annotations,  change  control 
processing  and  SGML  tagging  so  that  these  features  will  become 
more  standardized  and  universally  available; 

■  DMS  technology  will  remain  document  focused  for  awhile  so  it  will 
not  readily  or  efficiently  support  Type  C,  non-document  authoring; 

■  MIL-STD  1840  SGML  support  will  continue  to  evolve  towards  a 
productive  WYSIWYG  interface,  and  WYSIWYG  itself  will 
continue  to  improve  to  allow  on-screen,  interactive  fme  tuning 
of  quality  work  without  batch  runs;  and 

■  Advanced  technical  publishing  functionality,  such  as  full  text 
search,  will  appear  in  DMS  products. 


TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT'D) 


INDIVIDUAL 
TECHNOLOGY 
T2  (CONTD) 


TECHNICAL 
PUBLISHING: 
DOCUMENT 
MANAGEMENT 
SYSTEMS  (DMS) 


FY91-FY93  RISK 


ASSESSMENT 


DMS  is  a  key  AFTOMS  technology 
for  document  management  and 
change  control  which  still  could  have 
troublesome  residual  risks  in  the 
following  areas: 


Incomplete  integration  with  an 
RDBMS  (or  OODM)  to  readily 
support  cataloging,  tagging.  B  + 
enhancements,  change  control, 
minimally-redundant  data 
storage  and  fast  TO  retrieval. 


ABATEMENT 


The  Air  Force  could  abate  these 
risks  by  exploring  more  thoroughly- 


Using  DMS  products  that  inte¬ 
grate  DMS  and  RDBMS  technol¬ 
ogies  into  a  single  document  pub¬ 
lication,  management,  and  distri¬ 
bution  product  which  would  sim¬ 
plify  AFTOMS  design  and  main¬ 
tenance;  also,  considering  parti¬ 
tioning  and  distributing  TO  docu¬ 
ments  and  associated  data  for 
each  TOMA  over  multiple  data¬ 
base  servers  to  balance  the  weap¬ 
on  system  database  load  to  im¬ 
prove  AFTOMS  performance. 


LEGEND 


RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


Limited  integration  with  an  ODS 
so  that  B  +  lagging  performed  in 
the  DMS  is  not  fully  used  by  the 
ODS  in  the  Tier  4  WAs. 


Limited  integration  with  a  scan¬ 
ning  system  so  that  converted 
Type  A  TOs  cannot  benefit  from 
B  &  B+  capabilities  without  re¬ 
quiring  undue  manual  labor  to 
perform  the  tagging. 


Inadequate  support  for  interac¬ 
tive  SGML  authoring,  and  its 
difficulty,  productivity,  and 
accuracy  implications  for  down¬ 
stream  AFTOMS  functionality. 


Q  Determining  from  analysis  and  ex¬ 
perience,  the  level  and  types  of 
tagging  required  to  support  the 
Tier  4  users  to  reduce  the  tagging 
load  on  the  Tier  2  DMS  operators 
and  the  database. 

n  The  continuing  evolution  of  intel¬ 
ligent  scanning/editing  systems 
that  are  (or  can  be)  integrated 
with  a  DMS  product  which  will  fa¬ 
cilitate  smooth,  interactive  pro¬ 
cessing  of  scanned  TOs  into  Type 
B  or  B+  form. 

□  Completing  the  SGMJ  DTDs  in 
modules:  basic  requirements  for 
separation  of  content  &  format, 
then  additional  attributes  and  tags 
for  effective  display  of  TOs  as 
documents,  and  finally  more  addi¬ 
tional  tags  for  B+  hypermedia 
display  capabilities. 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


T3  INDIVIDUAL 
_ TECHNOLOGY 

DISTRIBUTED 

RELATIONAL 

DATABASE 

MANAGEMENT 

SYSTEMS 

(RDBMS) 

RELEVANCE: 

RDBMS  technolo¬ 
gy  was  developed 
during  the  1970s  to 
provide:  efficient 
data  access  struc¬ 
tures:  a  logical  ba¬ 
sis  for  formulating 
queries  to  retrieve 
desired  data  com¬ 
binations;  and 
physical  data  inde¬ 
pendence  (so  that 
database-using 
programs  need  not 
incorporate  logic 
that  describes  the 
h  ard  ware-dependent 
physical  scheme 
used  to  store  the 
data).  Network 
distributed  ver¬ 
sions  of  RDBMS, 
offering  partition¬ 
ing  of  databases 
and  transparent 
data  access 
throughout  the 
network,  emerged 
during  the  1980s. 

Given  the  POC 
work,  this  section 
assesses  RDBMSs, 


STATE  OF  THE  TECHNOLOGY 


RDBMS  is  a  mature,  yet  robust  database  technology  of  choice  that  has  a 
large  installed  base  and  is  being  developed  further,  as  follows,  to  make  it 
even  more  productive: 

■  All  major  products  support  the  TCP/IP  networking  standard  for 
interconnecting  their  RDBMS  on  distributed  heterogeneous 
workstations,  and  vendors  are  working  on  their  X-window  support; 

■  Products  are  being  ported  to  popular  hardware  platforms,  but 
some  proprietary  workstations  are  not  yet  (or  won't  be)  supported; 

■  Access  transparency  across  different  RDBMS  products  on  the 
same  network  is  still  problematic  unless  ANSI  SQL  is  used  by  all 
products  to  send  transactions  to  each  other 

■  Scope  and  integration  of  supporting  development  tools,  4GL 
languages,  SQL  extensions,  etc.,  and  quality  of  query  optimization 
vanes  among  the  products,  but  is  being  improved;  and 


■  All  major  products  still  must  solve  the  distributed  database  update 
problem  to  assure  database  integrity  at  all  times,  even  when  some 
equipment  malfunctions  during  processing  of  a  data  update. 


During  this  period,  only  heterogeneous,  workstation-based  RDDMS  prod¬ 
ucts  running  under  UNIX  in  a  X-window  distributed  environment  are  rele¬ 
vant  to  AFTOMS;  and  a  good  choice  of  competing  quality  products  will  be 
available.  Products  from  major  vendors  should  all: 

»  Be  compliant  with  PCSIX,  OSL,  and  ANSI  SQL  standards; 

■  Offer  extensive  integrated  development  and  end-user  toolkits  that 
exceed  today's  best; 

•  Have  fairly  well  solved  the  distributed  database  update  problem  for 
their  own  products,  but  problems  (in  coordinating  data 
dictionaries,  data  search  path  optimization,  etc)  will  probably 
remain  if  different  RDBMS  products  are  used  in  the  AFTOMS  or 
CALS-integrated  architecture;  and 

■  Respond  to  the  OODM  challenge  by  providing  comparable,  but 
somewhat  limited  object-oriented  capabilities  that  offer  better 
price/performance. 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


INDIVIDUAL 
TECHNOLOGY 
T3  (CONTD) 


DISTRIBUTED 

RELATIONAL 

DATABASE 

MANAGEMENT 

SYSTEMS 

(RDBMS) 


LEGEND 

RISK  ASSESSMENT 
SYMBOLS: 


D 

§ 

D 


HIGH 


MEDIUM 


LOW 


FY91-FY93  RISK 


ASSESSMENT 

Unless  obviated  by  an  advanced 
DMS  which  incorporates  or  sup¬ 
ports  ail  the  necessary  data  models, 
distributed  RDBMS  technology  run¬ 
ning  in  a  heterogeneous,  X -window 
and  UNIX-based  environment  is  a 
key  integrating  mechanism  for  TO- 
related  data  and  for  future  integra¬ 
tion  with  CALS.  In  a  well-inte¬ 
grated  and  locally-distributed  envi¬ 
ronment,  RDBMS  technology  should 
pose  no  significant  buildability  or 
usability  obstacles  in  handling  the 
required  AFTOMS  data  types  and 
functionality.  Distributed  RDBMS 
technology  may  have  residual  risks 
in  the  following  areas: 

Maintaining  data  consistency  and 
integrity  if  heterogeneous 
RDBMS  products  are  networked 
together  in  a  distributed  and 
integrated  CALS  architecture. 


B  Degraded  performance  if 

RDBMS  processing  and  data  are 
distributed  over  a  wide-area 
network. 


D  Inadequate  performance  under 
full-scale  AFTOMS  data'opera- 
tor/and  communications  loading 
if  the  system  architecture  cannot 
provide  adequate  data,  communi¬ 
cations,  and  hardware  capacities. 


ABATEMENT 

The  Air  Force  could  abate  these 
risks  by  exploring  the  following 
architectural  and  design  options: 


□  Defining  standardized  interface 
requirements  for  other  TO  and 
CALS  systems  to  meet;  and  using 
only  baselined,  standards-con- 
forming  technologies  (e.g.,  SQL) 
to  assure  adequate  interoperabil¬ 
ity. 


El  Limiting  replication  of  data  & 
processing,  message  &  data  traffic 
between  selected  wide-area  AF¬ 
TOMS  nodes,  batching  of  queries 
and  using  delayed  off-peak  turna¬ 
round  response . 

□  Database  partitioning,  and  special¬ 
ized  search  algorithms  to  take  ad¬ 
vantage  of  the  AFTOMS  tiered 
structure /TO  characteristics/or  as¬ 
sociated  data  to  maximize  per¬ 
formance  if  necessary. 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


X4  INDIVIDUAL 

TECHNOLOGY 


USER 

INTERFACE 
MANAGEMENT 
SYSTEMS  (DIMS) 

RELEVANCE: 

Different  classes  of 
users  (managerial, 
technical,  edito¬ 
rial,  production 
and  Tier  4  mainte¬ 
nance)  will  coexist 
and  need  to  be 
supported  by  AF¬ 
TOMS.  The  goal 
is  to  make  all  AF¬ 
TOMS  users  more 
productive  through 
intelligent  require¬ 
ments  definition 
and  system  design. 
A  key  element  of 
that  system  design 
involves  the  user 
interfaces  which 
represent  AF¬ 
TOMS  to  users. 

Given  the  POC 
work,  this  section 
assesses  UIMS 
technology  and  its 
capabilities  for 
building  and  modi¬ 
fying  the  various 
types  of  hardware- 
independent  user 
interfaces  needed 
in  AFTOMS. 


STATE  OF  THE  TECHNOLOGY 


Fundamentally,  the  UIMS-developed  interface  performs  three  major  tasks: 

*  Mediates  control  of  the  dialog  between  the  user  and  the 
application  software  that's  processing  inside  the  computer 

■  Acquires  user-entered  commands,  data  inputs,  and  validates  them, 
thereby  defining  the  use  of  keyboard,  function  keys,  mouse 
buttons,  and  other  pointing  devices  for  the  application  system;  and 

■  Handles  all  the  user-visible  portions  of  the  interface  including  the 
placement  and  appearance  of  all  messages,  data,  and  graphic 
objects,  cursor  movement,  scrolling,  window  management,  etc. 

Using  the  UIMS  approach  produces  a  superior  quality  traditional  charac¬ 
ter-oriented  or  a  modem  graphically-oriented  user  interface  (GLH);  it 
avoids  potentially  serious  design  flaws;  and  it  lowers  the  cost  of  design  and 
future  maintenance  changes.  X-Wmdows  allows  user  interface  portability 
across  heterogeneous  hardware  platforms. 

A  UIMS  is  an  integrated  set  of  tools  for  mpid  construction  of  UIs;  these 
tools  are  integrated  with  runtime  libraries  and  macros  for  specifying 
standard  interface  features.  Currently,  most  UIMS  products  are  not  really 
sufficiently  standardized,  general,  or  flexible  enough  to  be  design  tools  or 
to  be  easily  programmable  since  they: 

•  Offer  a  limited  set  of  capabilities  and  a  programming  language  at 
most; 

■  Don’t  support  user  interface  transition  from  prototyping  to  final 
product  development;  and 

■  Don’t  share  consistent  meaning  with  the  applications  code. 

UIMS  technology  is  just  emerging  into  commercial  use,  ind  the  available 
products  reflect  the  immaturity  of  the  technology  and  the  lack  of  applica¬ 
tion  developer  feedback  from  building  and  using  large-scale  systems.  Oth¬ 
er  limitations  include  need  for  powerful  workstations  with  high-resolution 
color  monitors  to  support  the  heavy  processing  and  graphics  of  GUIs. 

FY91-FY93: 

Current  GUI  market  fragmentation,  product  immaturity  and  stability,  lack  of 
common  functionality  coverage,  and  performance  problems  typical  of  an 
emerging  technology  should  resolve  themselves  in  the  next  few  years  as  the 
technology  matures.  De  facto  standards  will  emerge.  The  Open  Software 
Foundation  (OSF)  UI  framework  will  probably  become  the  underlying  model 
for  X-Windows,  UNIX-compatible,  distributed  GUIs  as  major  competitors 
(e.g.,  AT&T  and  SUN)  add  their  support  to  it. 

Next-generation  advances  in  hardware  performance  will  help  improve  GUI 
performance  in  terms  of  speed  and  graphical  resolution  at  a  lower  cost. 
Specialized  graphics  servers,  X-terminals,  and  adapted  personal  computers 
will  also  become  available  to  run  GUIs.  Extensions  for  support  of  multi- 
media,  new  pointing  devices,  and  widget  classes  will  undoubtedly  emerge. 


TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


INDIVIDUAL 
TECHNOLOGY 
T4  (CONTD) 


USER 

INTERFACE 
MANAGEMENT 
SYSTEMS  (UIMS) 


FY91-FY93  RISK 


LEGEND 


RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


LOW 


ASSESSMENT 


Next  generation  high-resolution 
graphic  workstations  provide 
AFTOMS  developers  the  opportuni¬ 
ty  to  refine  and  design  productive 
UIs  for  AFTOMS.  However,  design¬ 
ing  and  developing  good  UIs  has  be¬ 
come  more  complex  and  difficult  as 
the  designer  must  be  concerned  with 
multiple  windows,  the  use  of  color 
and  shading,  graphical  objects  and 
icons,  networking,  heterogeneity  in 
hardware  platforms,  and  various 
on-screen  selection  techniques. 

Thus,  residual  risks  are  present  in 
the  following  areas: 

n  Available  UIMS  toolsets  will  not 
S  fully  support  productive  develop- 
— I  ment  of  GUIs,  thereby  increasing 
the  cost  and  reducing  the  flexibil¬ 
ity  of  refining  the  initial  GUIs. 


GUI  designers  may  opt  to  under¬ 
design  AFTOMS'  UIs  settling 
for  traditional  approaches  which 
result  in  hard  to  learn  and  use 
UIs:  and  which  can  impact  user 
productivity,  training,  initial  ac¬ 
ceptance,  and  future  upgrading 
of  AFTOMS. 


GUIs  may  not  be  feasible  on  all 
AFTOMS  or  Tier  4  hardware 
platforms. 


Performance  of  networked  GUIs 
may  be  somewhat  slow. 


ABATEMENT 


The  Air  Force  could  abate  these 
risks  by. 


Selecting  a  UIMS  technology 
product  that  offers  a  set  of  inte¬ 
grated  software  tools  for  the  defi¬ 
nition  and  execution  of  GUIs,  and 
a  high-level  specification  language 
for  describing  the  dynamic  events 
and  interactions  that  make  up 
each  AFTOMS  GUL  also,  by 
defining  early  a  common  GUI  ex¬ 
ecutive  that  abstracts  a  consistent 
core  of  GUI  services  and  user  dia¬ 
log  techniques  which  can  then  be 
adapted  to  each  specific  GUI. 

Keeping  the  GUIs  independent  of 
the  application  programs,  building 
on  the  POC  Demo  System  GUIs, 
and  using  a  flexible  prototyping 
approach  that  integrates  feedback 
from  potential  users  should  result 
in  good  quality  GUIs. 


□  Cost  and  performance  obstacles  to 
bit-mapped  GUI  workstations  are 
falling  rapidly,  so  design  GUIs  for 
future  not  past  hardware. 

f~l  Improved  X -Windows,  X-Server, 
and  other  specialized  products, 
network  balancing,  and  overall  ad¬ 
vances  in  HW  will  overcome  a 
short-term  performance  problem. 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


T5  INDIVIDUAL 

TECHNOLOGY 


ON-LINE 
DELIVERY 
SYSTEMS  (ODS) 


RELEVANCE: 

An  important  goal 
of  AFTOMS  is  to 
improve  the  pro¬ 
ductivity  of  Tier  4 
maintenance  tech¬ 
nicians  through  ef¬ 
fective  use  of  TOs. 
ODS  technology 
can  provide  the  TO 
user  task/configu- 
ration/& experience 
level  customized 
views  of  the  data, 
graphical  manipu¬ 
lation  capability  to 
access  the  data 
better,  branching/ 
referencing  links  to 
navigate  quickly  to 
relevant  portions 
of  the  data,  etc. 
These  advanced  ca¬ 
pabilities  require 
insertion  of  hyper¬ 
text  tag  elements 
into  TOs. 

Given  the  POC 
work,  this  section 
assesses  the  capa¬ 
bilities  of  ODS 
technology  and  its 
relationship  to 
DMS  technology. 


STATE  OF  THE  TECHNOLOGY 
FY89:  | 

ODS,  currently  offers  advanced  on-line  display  capabilities,  such  as: 

■  The  display  of  fully  composed  pages  (containing  text  and  graphics) 
on  a  high  resolution  graphics  display  or  laser  printer, 

■  Multiple  windows  for  displaying  multiple  pages  and/or  TOs; 

■  Graphic  manipulation  (zoom,  rotate); 

■  Hypertext  links; 

■  Translation  of  references  in  text  to  links; 

■  Maintaining  the  integrity  of  complex  manuals  (text,  graphics, 
tables,  external  and  internal  references); 

■  Optical  disk  nrxess; 

■  Fast  page  access  through  page  caching;  and 

■  Annotation  capabilities. 

With  additional  work,  an  ODS  can  display  customized  views,  such  as  skill  level 
or  configuration  variants.  Some  ODS  user  interfaces  are  also  programmable, 
allowing  customizable  interfaces  with  the  user.  The  display  of  multiple  pages 
and  the  ability  to  turn  two  pages  at  a  time  is  also  possible.  There  is  presently 
only  partial  automation  of  hypertext  link  implementation,  which  is  essential  for 
a  cost  effective  solution  to  Type  B  +  TOs.  Vendors  are  continuing  to  develop 
annotation  capabilities  and  version  control  mechanisms.  The  development  of 
a  direct  link  between  a  DMS  and  ODS  is  essential  to  enable  AFTOMS  users  to 
submit  AFT022s  productively. 


ODS  will  continue  to  mature  with  improvements  in  performance,  better  dis¬ 
play  quality,  more  B+  functionality,  better  search  and  retrieval  algorithms 
and  a  link  between  the  ODS  and  a  DMS;  the  access  time  for  page  viewing  and 
hypertext  linking  will  also  decrease.  As  workstation  costs  decrease  and  more 
X-terminals  become  available,  ODSs  will  better  exploit  the  potential  for 
Fault  Isolation  based  expert  systems;  and  ODSs  be  distributed  more  frequent¬ 
ly  with  commercial  and  technical  publishing  systems.  These  advancements 
will  allow  DMS  vendors  to  investigate  the  incorporation  of  more  B+  func¬ 
tionality  into  their  on-line  delivery  systems. 

By  FY93,  an  ODS  should  be  able  to  deliver  all  the  functionality  needed  to 
support  a  Using  Command  delivery  system,  resident  at  Tier  2  (for  TO  verifica¬ 
tion)  and  Tier  4  (for  maintenance),  that  includes  all  the  advanced  capabilities 
listed  above  for  ODS.  Therefore,  the  AFTOMS  system  will  be  able  to  display 
Type  B  documents  at  a  minimum;  and  implementation  of  Type  C  will  also  re¬ 
quire  some  form  of  ODS  technology  to  display  TO  views  at  Tiers  2  and  4. 


TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT'D) 


IN  DIM  DUAL 
TECHNOLOGY 
T5  (CONTD) 


ON-LINE 
DELIVERY 
SYSTEMS  (ODS) 


FY91-FY93  RISK 


LEGEND 


RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


LOW 


ASSESSMENT 


ODS  is  a  key  AFTOMS  delivery 
mechanism  for  TOs  in  FY91-FY93. 
The  POC  Demo  System  activity 
showed  that  ODS  technology  is  de¬ 
veloping  in  a  productive  direction 
for  on-line  delivery  of  TOs  and  cus¬ 
tomized  views.  Residual  risks  are 
present  in  the  following  areas: 

“j  The  link  between  the  ODS  and  a 
■  DMS  may  not  be  adequately  inte- 
—*  grated.  The  links  and  tags  that  are 
used  to  traverse  a  TO  in  the  ODS 
must  be  embedded  in  the  TO  text 
prior  to  delivery.  In  the  POC,  a 
DMS  was  used  to  insert  these  tags 
manually  using  both  SGML  and 
other  tagging  mechanisms.  Auto¬ 
mation  of  such  tagging  is  being  de¬ 
veloped  today  and  should  be  avail¬ 
able  in  the  early  1990s.  Integration 
of  publishing  systems  and  ODSs  is 
also  being  undertaken.  During  TO 
creation,  DMSs  allow  multiple  au¬ 
thors  to  add  content  inputs  in  the 
form  of  graphics,  text,  tables,  data, 
and  composition.  For  ODS,  an  easy 
way  for  multiple  authors  to  add  hy¬ 
pertext  links  to  documents  will  also 
need  to  be  devised. 

□  Validation  and  Verification  must  be 
I  performed  on  all  ODS  customized 
— '  views  as  well  as  TOs,  thereby  adding 
to  the  Tier  2  workload. 

The  size  and  complexity  of  each  TO 
J  could  cause  performance  problems 
™  in  the  delivery  and  display  of  TOs 
on  MAJCOM’s  delivery  systems. 
Full-scale  AFTOMS  data,  opera¬ 
tor,  transaction,  change  control, 
loading,  and  performance  could  not 
be  evaluated  in  the  Demo  System  . 


ABATEMENT 


The  Air  Force  could  abate  these 
risks  by: 


pi  Monitoring  integration  of  ODS  and 
DMS  products  into  a  single  docu¬ 
ment  publication  &  delivery  product, 
and  looking  for  developments  in  the: 

•  Ability  to  create  customized 
views  and  display  them  in  a  user 
“friendly”  manner  using  low  light 
colors  or  whiting  out  to  mark  in¬ 
appropriate  text  and  graphics; 

■  Cataloging  and  retrieval  capabili¬ 
ties  needed  for  the  end-user  to 
access  the  appropriate  TO  and 
task  information; 

■  Possibility  of  ODS  support  of  lim¬ 
ited  data  entry  for  AFT022s;  and 

*  Possibility  of  SGML  external  and 
internal  reference  tags  being  au¬ 
tomated  into  hypertext  tags.  Tb 
accept  Type  B+  TOs  from  the 
contractor  the  MIL-STD-1840 
standards  will  need  to  have  ele¬ 
ment  types  for  hypertext  links. 
Otherwise  AFTOMS  will  need  to 
enhance  Type  B  documents  inter¬ 
nally  upon  acquisition  and  as  part 
of  change  processing. 

PI  Reducing  workload  by  verifying  only 
the  TOs  and  views  shown  at  Tier  4. 

f~l  Considering  distribution  of  TOs  and 
data  over  multiple  database  servers 
and  increasing  workstation  memory. 

Note  that  ODS  benefits  to  the  Air  Forte 
outweigh  initial  Tier  2  labor  &  system 
performance  costs 


TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


T6  INDIVIDUAL 

TECHNOLOGY 


LOCAL  AREA 
COMMUNICATIONS 

RELEVANCE: 

The  electronic 
transfer  of  digital 
information  within 
workgroups,  de¬ 
partments,  build¬ 
ings,  and  bases 
has  become  the  do¬ 
main  of  Local  Area 
Network  (LAN) 
technology.  Ad¬ 
vances  in  this  tech¬ 
nology  and  its 
standardization  of¬ 
fer  great  promise 
in  supporting  the 
AFTOMS  intra¬ 
tier  and  intra-base 
communications 
needs.  Adherence 
to  the  AF  Unified 
LAN  Architecture 
(ELAN A)  stan¬ 
dards  will  ensure 
interoperability 
and  the  latest  tech¬ 
nologies  available. 

Given  the  POC 
work,  this  section 
assesses  LAN  tech¬ 
nology  and  its  abil¬ 
ity  to  support  HW 
heterogeneity  and 
the  distribution  of 
AFTOMS  func¬ 
tionality 


STATE  OF  THE  TECHNOLOGY 


FY89: 


Installation  of  LANs  in  place  of  traditional  minicomputer/terminal  architec¬ 
tures  has  continued  to  increase.  Ethernet  and  Token  Ring,  now  considered 
as  mature  LAN  access  protocols,  have  emerged  as  the  most  popular  proto¬ 
cols.  Ethernet  has  enjoyed  growth  because  of  its  lower  cost  and  favor  with 
workstation  manufacturers.  Currently,  Ethernet  has  the  greatest  installed 
base  with  approximately  50%  of  the  market  versus  Token  Ring’s  12%. 

The  Fiber  Data  Distributed  Interface  (FDDI)  which  standardizes  the  physi¬ 
cal  interface  to  optical  fiber  for  100Mbps  transmission  is  emerging.  FDDI  is 
viewed  as  the  coming  standard  for  fiber  optic  communication  backbones  and 
will  offer  support  for  both  Ethernet  and  Token  Ring  protocols. 

Bridge  and  gateway  technology  has  continued  to  increase  performance. 
Bridge  performance  for  either  LAN  protocol  is  considered  equally  robust. 
Link  Access  or  Medium  Access  Control  (MAC)  layer  bridges  have  become 
popular  in  connecting  geographically  separated  LANs  using  a  wide  area  link 
such  as  a  telephone,  T1  line  (1.544  Mbps)  or  satellite  link.  For  casual  termi¬ 
nal  access,  a  9.6  Kbps  dial-up  line  is  enough.  For  large  file  transfers  like 
TOs,  a  56  or  64  Kbps  leased  line  is  necessary.  Very  heavy  traffic  (or  video 
and  voice)  will  require  a  T1  line. 

The  commercial  and  DoD  development  environments  (using  RDBMS  sys¬ 
tems)  have  continued  to  rely  on  TCP/IP  and  IP  host  sockets  as  the  basis 
upon  which  distributed  applications  are  built.  All  leading  workstation  ven¬ 
dors  have  increased  their  support  for  TCP/IP. 

User-friendly  front-end  packages  for  Unix  mail  have  been  scarce,  but  sup¬ 
port  for  X -Window  and  the  X  4Q0  standard  will  rhanee  this  s 


FY91-FY93: 


The  popularity  of  both  Ethernet  and  Token  Ring  LANs  will  continue 
through  this  period.  FDDI  will  be  pursued  heavily  as  a  backbone  for  bridg¬ 
ing  Ethernets  or  Token  Ring  LANs.  The  growth  of  fiber  optic  bridging  tech¬ 
nology  matches  the  Air  Force  LITA  goals  which  specify  fiber  optic  cable  for 
interconnection  of  depanmental  LANs.  Heavy  traffic  LANs,  used  where 
requirements  exceed  standard  10  Mbps  rates,  undoubtedly  will  transition  to 
fiber  optics.  Fiber  optic  cabled  LANs  will  also  be  used  to  reduce  the  effects 
of  electromagnetic  and  radio  interference. 

The  interconnection  of  geographically  remote  LANs  will  increase  as  the 
popularity  of  layer  bridges  exceeds  that  of  traditional  gateways.  ISDN  will 
start  to  become  popular  as  a  LAN-WAN  transport  specification  during  this 
timeframe.  Bridge  performance  will  approach  a  filtering  and  transfer  rate 
exceeding  T1  (1.544Mbps). 

Support  for  ISO  protocols  will  become  more  widely  available  from  most 
vendors.  However,  the  acceptance  of  TP4  in  place  of  TCP  will  be  a  long 
and  difficult  transition  so  in  this  area  the  government’s  push  for  GOSIP 
may  need  to  go  slow  even  though  GOSIP  guidelines  will  begin  to  be  strictly 
adhered  to  for  new  system  acquisitions. 

Gateways  between  existing  DoD  protocols  and  ISO  will  become  a  reality. 
X.400-based  electronic  mail  and  Message  Handling  Services  (MHSs)  will 
become  the  standard. 

User-friendly  windows  and  menus  based  on  X-windows  will  allow  graphical 
front-ends  to  be  built  for  the  UNIX-environment  increasing  usability. 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


INDIVIDUAL 
TECHNOLOGY 
T6  (CONTD) 


FY91-FY93  RISK 


ASSESSMENT 


The  functional  capability  of  LAN 
technology  is  considered  a  low  tech- 
LOCAL  AREA  nological  and  cost  risk.  Some  other 

rAMHT'vir»TiAvc  residual  risks  are  present  and  the 

following  points  need  to  be  consid¬ 
ered  in  assessing  the  risks  in  LAN 
technology  selection: 

B  Providing  adequate  LAN  per¬ 
formance  is  the  greatest  risk  in 
selecting  a  LAN  for  AFTOMS. 
Ethernet  appears  to  offer  ade¬ 
quate  speed  for  file  transfer  and 
transaction  processing  for  depart¬ 
mental  LANS  (generally  10-20 
workstations)  with  less  than  60 T 
utilization.  Heavy  traffic  LANs 
should  consider  deterministic  ac¬ 
cess  methods  such  as  Token 
Ring. 


Commercial  application  software 
to  be  integrated  into  AFTOMS 
may  not  run  on  all  LANs  or  HW 
platforms  thereby  setting  some 
constraints  that  need  to  be  met. 


LEGEND 

RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


DoD  protocols  are  being  re¬ 
placed  with  ISO.  therefore,  a  mi¬ 
gratory  upgrade  path  needs  to  be 
considered  in  selecting  any  LAN 
products. 


ABATEMENT 


The  Air  Force  could  abate  these 
risks  by: 

l~|  Traffic  analyses  and  modeling 
should  be  performed  on  AF¬ 
TOMS  tiers  with  a  full  weapon 
system  suite  of  TOs  to  determine 
proper  LAN  loading  parameters 
for  each  tier.  A  fully-featured 
Network  Operating  System  should 
be  investigated  for  its  capabilities 
to  support  file  transfer,  security, 
distributed  processing,  network 
management,  and  diagnostics. 

Key  software  such  as  DMS  and 
RDBMS  needs  to  be  evaluated 
and  selected  before  selecting 
workstations  and  LANs. 

[~1  The  existing  physical  environment 
at  each  AFIOMS  tier  and  loca¬ 
tion  should  be  surveyed  to  deter¬ 
mine  backbone  LAN  availability, 
cabling  constraints,  bridges  and 
gateways.  Then: 

■  ULANA  I  and  II  guidelines 
should  be  used  to  select  LAN 
systems  and  vendors; 

■  CTO  DO  and  Work  Area 
LANs  should  be  designed  in 
consideration  of  the  LITA 
plan  for  that  base; 

■  TCP/IP  is  the  best  choice  for 
transport  layer  protocol  over 
the  next  five  years  until 
TP4/IP  matures; 

■  Since  inter-tier  long-haul 
traffic  will  consist  primarily  of 
database  transactions  and 
electronic  mail,  gateways 
rather  than  bridges  offer  ma¬ 
ture  solutions  in  connecting 
to  wide  area  X.25  networks 
such  as  the  DDN;  and 

■  X.400  support  for  mail  and 
NFS  support  for  HW  hetero¬ 
geneity  should  be  required  as 
part  of  the  Network  Operat¬ 
ing  System  that  is  selected. 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


77  INDIVIDUAL 

TECHNOLOGY 


WIDE  AREA 
COMMUNICATIONS 

RELEVANCE: 

Wide  area  Network 
(WAN)  technology 
provides  for  Jong 
haul  transfer  of 
digital  information 
between  AF¬ 
TOMS  tiers  and  to 
external  contrac¬ 
tors.  WAN  trans¬ 
fer  of  all  TOs  is 
not  considered 
feasible  because  of 
excessive  commu¬ 
nications  expense 
and  inadequate 
performance. 
Instead,  only 
transactions  (e.g., 
status,  AFT022s, 
profiles,  etc.)  and 
time-compliant 
TOs  will  be  trans¬ 
ferred  this  way 

Based  on  the  POC 
scope  and  its  co¬ 
located  equip¬ 
ment,  WAN  data 
transfer  was  not 
included  in  the 
Demo  System.  This 
section  assesses  the 
WAN -related  is¬ 
sues  for  AFTOMS 
communication 
technology  needs. 


STATE  OF  THE  TECHNOLOGY 


Long-haul  transmission  facilities  include  TelCo  circuit  offerings  as  well  as 
Value-added  Networks  (VANs).  All  carriers  are  upgrading  backbone  net¬ 
works  with  T1  (1.544  Mbps)  facilities  in  anticipation  of  greater  demand. 
Fractional  T1  services  are  emerging  which  allow  switches  to  utilize  64  Kbps 
increments  of  Tl.  VANs  are  continuing  to  upgrade  services.  The  costs  of 
packet  switched  services  are  stabilizing  to  offer  an  attractive  alternative  to 
building  private  networks  or  leasing  private  lines.  Communication  access 
products  include  modems,  bridges  and  gateways  that  offer  connectivity  be¬ 
tween  the  AFTOMs  host  or  LAN  and  a  long  haul  transmission  facility. 

Bridge  and  gateway  technology  has  improved  and  offers  transparent  ser¬ 
vices  between  LANs.  Link  layer  protocol  bridges  have  become  popular 
since  they  allow  higher  level  protocols  to  be  transported  transparently  over 
the  network.  X.25  and  TCP/IP  gateway  services  are  readily  available.  The 
combined  use  of  TCP/IP  over  X.25  linL  is  not  considered  a  high  technolo¬ 
gy  risk.  X.25  and  asynchronous  boards  are  available  which  install  in  PCs  or 
the  LAN  communications  server  and  offer  remote  long  haul  connectivity  . 
Most  gateway  vendors  offer  support  for  transmission  rates  to  64  Kbps  while 
a  few  offer  Tl. 

Advanced  data  compression/error  control,  fall-back  speeds,  and  dial- 
back-up  features  have  made  V.32  modems  popular  for  high  speed  dial  up 
connections  and  a  rising  star  in  modem  technology.  Under  ideal  circum¬ 
stances  these  modems  have  provided  19.2  Kbps  full  duplex  operation. 

ISDN  offerings  have  been  primarily  testbeds  for  implementation  on  a  small 
scale.  Carriers  have  been  increasing  their  ISDN  switch  upgrades  but  few 
vendors  are  offering  full  ISDN  support  for  customer  premises  equipment. 

Fiber  optic  lines  by  TfelCos  will  become  widespread  and  their  use  for  local 
and  premise  wiring  will  increase.  Fiber  optic  cable  and  modems  are  de¬ 
creasing  in  price  along  with  the  growth  of  Fiber  Distributed  Data  Interface 
(FDD1)  products. 

FY91-FY93:  | 

Modem  product  offerings  in  this  timeframe  will  decrease  the  cost  of  V.32 
and  V.22  modems  and  increase  throughput  performance. 

ISDN  access  services  will  be  offered  in  almost  all  major  city  markets  by  lo¬ 
cal  and  intercxchange  carriers.  ISDN  phones  and  computer  interface  cards 
compatible  with  the  ISDN  Basic  Rate  Interface  will  increase  in  numbers  as 
premise  ISDN  PBXs  and  TfelCo  access  services  will  grow  in  number  and 
cost  effectiveness.  ISDN  and  X-25  host  interface  cards  will  be  popular 
items.  ISDN  gateways  will  be  offered  as  a  common  solution  for  connecting 
remote  LANs.  Even  with  increased  digital  services,  dial-up  and  leased  ana¬ 
log  lines  will  continue  to  be  the  predominant  long-haul  transmission  re¬ 
source  for  small  to  medium  sized  users. 

Competition  between  CATV'  and  telephone  carriers  for  local  transport  ser¬ 
vices  will  increase.  Both  video  and  wideband  data  services  will  be  offered 
given  bandwidth  availability  and  advances  in  compressed  video  technology. 
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INDIVIDUAL 
TECHNOLOGY 
T7  (CONTD) 


WIDE  AREA 
COMMUNICATIONS 


FY91-FY93  RISK 


LEGEND 


RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


ASSESSMENT 


Wide  area  loDg-haul  communica¬ 
tions  is  considered  a  low  technologi¬ 
cal  risk  since  networks  and  equip¬ 
ment  are  available  to  support  the 
transaction-oriented  traffic  planned 
for  the  AFTOMS  inter-tier  network. 
Expected  residual  risks  are  asso¬ 
ciated  with  proper  planning  and 
provisions  for  network  security: 

H  Implementation  must  be  timed  to 

■  take  advantage  of  existing  or 

-J  planned  long-haul  resources  at 

the  base  level;  this  includes  dial¬ 
up  service,  leased  line,  and  DDN 
or  PDN  services. 

~ 1  Response  time  and  throughput 
I  performance  may  not  be  adequate 

■  with  existing  or  planned  resources. 

“1  Expense  containment  must  be 
I  considered;  costly  high-bandwidth 

■  long-haul  telecommunications,  T1 
carrier  or  subrate  Tl,  should  only 
be  considered  for  high  volume 
traffic  such  as  that  between  ALC 
Data  Centers;  the  communica¬ 
tions  architecture  should  restrict 
traffic  to  updates  and  queries  until 
technology  and  costs  justify  near- 
real  time  transfer  of  bulk  TOs. 

D  Interoperability'  between  systems 
will  remain  a  risk.  ISO  protocols 
should  be  used  wherever  possible 
for  long  haul  transmission;  this  in¬ 
cludes  ISDN,  TP4/IE  and  X.25  as 
well  as  application  layer  protocols 
of  X.400,  FTAM,  and  VTP;  ISO, 
however,  will  not  be  widely  im¬ 
plemented  throughout  the  AF 
during  the  initial  fielding  of  AF¬ 
TOMS. 

D  Providing  adequate  security  for 
both  the  network  and  classified 
TO  information  will  depend  on 
near  term  technology  develop¬ 
ments. 


ABATEMENT 


The  Air  Force  could  abate  these 

risks  by  proper  planning: 

l~l  Due  to  the  LHTTA  upgrade  of  AF 
facilities,  it  is  expected  that  X.25 
gateway  services,  ISDN,  and  virtu¬ 
al  private  line  services  will  be 
available  for  access  by  AFTOMS; 
the  schedule  and  status  of  these 
upgrades  must  be  closely  factored 
into  planning  for  AFTOMS  wade- 
area  connectivity. 

I~l  Communications  modeling  of  the 
AFTOMS  architecture  should  be 
performed  to  forecast  traffic  load¬ 
ing  figures  needed  for  the  opera¬ 
tional  network  design  and  simula¬ 
tion;  initial  investigation  of  the  po¬ 
tential  traffic  and  geographic  dis¬ 
persion  of  sites  indicates  that: 

■  Use  of  a  packet  network  ser¬ 
vice  such  as  the  DDN  or  PDN 
is  feasible  for  providing  long- 
haul  interccnnectivity; 

■  Dedicated  leased  lines  should 
be  considered  for  the  high  vol¬ 
ume  of  expected  traffic  which 
will  occur  between  ALCs  for 
exchange  of  TOs  and  TO  re¬ 
view  information; 

■  TCP/IP  is  the  best  choice  of 
transport  layer  protocol  over 
the  next  five  years  due  to  its 
strong  vendor  support  and  em¬ 
bedded  base  of  DoD  users  for 
both  local  and  long-haul  com¬ 
munications;  and 

■  ISO  should  be  first  choice  at 
all  other  protocol  layers  with 
utilization  of  NIST-developed 
gateways  to  exchange  informa¬ 
tion  with  DOD  protocol  based 
systems. 

□  Communication  planners  need  to 
consider  multi-level  security  as  an 
option  in  transmitting  classified 
TO  information;  this  includes  in¬ 
vestigating  the  interim  use  of 
Blacker  and  the  future  DOD  Se¬ 
cure  Data  Network  System. 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT'D) 


T8  INDIVIDUAL 

TECHNOLOGY 


OPTICAL 

DISK 


RELEVANCE: 

AFTOMS  requires 
a  convenient,  high 
capacity,  inexpen¬ 
sive,  portable,  and 
stable  data  storage 
and  data  transfer 
medium  both  to 
reposit  its  TOs  and 
TO-associated 
data  at  Tier  2,  and 
bulk  distribute  the 
digitally  encoded 
weapon  system 
document  suites 
from  TOMAs  to 
the  CTODOs. 
Optical  disk  tech¬ 
nology  provides  the 
necessary  medium. 

Given  the  POC 
work,  this  section 
assesses  the 
practicality  of 
using  optical  disk 
technologies  (CD- 
ROM,  WORM, 
Erasable  Disk, 
etc.)  in  AFTOMS; 
and  concludes  that 
the  WORM  tech¬ 
nology  ofTers  the 
best  trade  off. 


STATE  OF  THE  TECHNOLOGY 


Each  TOMA  will  be  responsible  for  managing,  reporting,  and  distributing 
the  TO  suite  and  associated  data  for  a  single  weapon  system  -  a  maximum 
equivalent  of  about  1.2  million  pages  (at  30  kbytes  per  page  that’s  36  Giga¬ 
bytes  of  digital  data).  Reposited  data  storage  requirements  will  grow  cumu¬ 
latively  over  time  as  newly  acquired  IDs  and  each  distribution  cycle  are 
archived;  whereas,  the  size  of  each  successive  distribution  will  only  grow 
slowly  based  on  AFT022  changes  and  new  mods  to  the  weapon  system.  The 
AFTOMS  system  itself  will  produce  additional  TO-associated  data  (e.g.. 
profiles,  AFT022s,  abstracts,  cross-referencing,  content  tags  for  B+  capa 
bility,  SGML  codes,  component  reusability  linkages,  printer  control  codes, 
etc.)  to  make  the  TOs  more  accurate  and  usable  at  Tier  4;  such  associated 
data  will  also  be  reposited  and  distributed,  adding  maybe  20 T  to  the  TO 
inventory  .  Also,  for  planning  of  Type  C  TOs,  it  can  be  assumed  that  the 
storage  impact  of  reduced  redundancy  in  TO  components  will  be  offset  by 
increased  storage  for  database  view  descriptions  and  the  linkages  required 
to  reuse  database  components. 

Of  the  various  types  of  optical  media  available,  the  Write  Once  Read  Many 
(WORM)  times  technology  is  feasible  and  especially  suited  to  the  needs  of 
AFTOMS.  Generation  of  data  on  WORM  optical  disks  is  done  with 
worm  read'wTite  devices  which  attach  to  the  computer.  Software  provides 
a  transparent  interface  which  allows  the  user  to  access  the  WORM  device 
as  if  it  were  an  additional  hard  drive.  This  software  also  provides  file  alloca¬ 
tions  on  the  optica!  disks  and  file  name  serialization  for  maintaining  modi¬ 
fied  versions  cf  the  same  file.  Data  is  written  by  using  a  laser  to  melt  pits  in 
a  metallic  reflective  layer  embedded  in  the  optical  disk.  Data  is  read  by  de¬ 
tecting  reflectivity  differences  with  a  reduced  power  laser  beam.  This  re¬ 
sults  in  a  stable  image  which  is  immune  to  radiation  and  magnetic  in¬ 
fluences.  The  media  disk  is  secured  within  a  protective  carrier  to  prevent 
marring  of  the  surface  by  careless  handling.  The  following  are  the  key  is¬ 
sues  which  (as  a  group)  set  this  technology  apart  from  other  optical  disk 
technologies: 

■  Ease  and  low  cost  of  single  disk  creation  and  duplication; 

■  Inherent  audit  trails; 

*  Data  longevity  and  stability,  and 


*  Growing  acceptance  in  the  commercial  market. 

Its  onlv  practical  current  deficiencv  is  lack  of  format  standardization 


In  this  timeframe,  WORM  will  have  become  an  established  optical  disk 
technology;  it  is  converging  slowly  on  the  need  for  developing  and  adhering 
to  standardized  formats.  Media  information  density  should  improve  by  a 
factor  of  2-to-4  per  disk,  and  increased  commercial  acceptance  and  wide¬ 
spread  usage  should  reduce  costs  for  media  and  WORM  hardware.  Tfech- 
nology  advances  will  also  improve  media  stability  and  longevity,  making 
WORM  even  more  acceptable  for  archival  as  well  as  temporary  and  me¬ 
dium  term  use. 


TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


INDIVIDUAL 
TECHNOLOGY 
T8  (COST'D) 


FY91-FY93  RISK 


LEGEND 

RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


ASSESSMENT 


Industry  and  POC  experience  with 
Write  Once  Read  Many  (WORM) 
times  optical  disk  technology  has 
demonstrated  that  TOs  and  TO- 
associated  data  can  be  written,  read 
and  printed  with  a  reliability  which 
meets  AFTOMS  needs.  Data  accu¬ 
racy  is  assured  within  the  WORM 
technology  by  multi-level  error  re¬ 
covery  techniques  which  can  be 
supplemented  with  additional  data 
security  techniques  to  any  confi¬ 
dence  level  required.  Residual  tech¬ 
nological  risks  exists  in  the  follow¬ 
ing  four  areas: 

B  Acceptability,  will  the  media  be 
acceptable  under  existing  stan¬ 
dards  for  data  transfer  and/or 
archiving? 


Obsolescence:  in  a  changing 
technology,  how  long  will 
specific  proprietary  technology- 
products  available  today  remain 
on  the  market  or  be  supported  in 
the  future?  At  issue  are  both 
disk  format  compatibility  and 
availability  of  disks  and  spare 
parts  for  the  hardware. 


Practicality:  the  masses  of  data 
which  must  be  stored  on  W'ORM 
disks  require  an  effective  and 
workable  means  of  gathering  the 
data  at  Tier  2  for  writing  and  a 
practical  method  of  extracting 
and  securely  storing  the  data  for 
distribution  at  Tier  3. 


Ease  of  use:  does  the  system 
support  productive  use  by  typical 
computer  operations  staff  both 
at  Tier  2  and  Tier  3?  Is  field  in¬ 
stallation  and^r  replacement  a 
viable  undertaking? 


ABATEMENT 


The  Air  Force  could  abate  these 
risks  by: 


Even  though  technological  at¬ 
tributes  and  usage  experience  in¬ 
dicate  that  optical  media  are 
trustworthy  for  long-term  data 
storage,  the  technology  is  too  re¬ 
cent  and  not  well-enough  estab¬ 
lished  to  have  been  accepted  by 
the  government  for  permanent 
data  archiving  purposes;  there¬ 
fore,  it  will  be  necessary  to  pro¬ 
vide  archival  copies  by  currently 
acceptable  (paper  or  microfilm) 
methods  until  the  optical  me¬ 
dium  is  established  and  ac¬ 
cepted. 

The  rate  of  change  of  optical 
and  other  storage  technologies  is 
such  that  no  technology  available 
today  can  be  expected  to  persist 
unchanged  for  the  life  of  a  typi¬ 
cal  weapons  system.  Adherence 
to  industry  standards  will  maxi¬ 
mize  the  effective  life  of 
WORM  based  data,  and  planned 
automated  transcription  of  that 
data  to  new  generations  of  hard¬ 
ware  under  future  standards  will 
preserve  its  ready  availability 
indefinitely. 

Design  of  the  AFTOM^  syste.,. 
and  associated  operational  pro¬ 
cedures  can  provide  the  neces¬ 
sary  levels  of  practicality  and 
ease  of  use. 


TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT'D) 


-j-9  INDIVIDUAL 

TECHNOLOGY 

DEMAND 

PRINTING 

RELEVANCE: 

Today,  TOs  are 
printed  at  the 
ALCs  and  then 
distributed  or 
mailed  to  depots 
and  operating 
bases.  AFTOMS 
will  reverse  these 
functions:  first, 
bulk  distributing 
TOs  digitally  from 
Tier  2  to  Tier  3, 
then  selectively 
printing  TOs  or 
pages  within  them 
Ln  CTODOs  or  in 
Tier  4  Work 
Areas.  This  ap¬ 
proach  also  per¬ 
mits  printing  TO- 
associated  and 
management  data. 
A  key  technology 
that  allows  this 
flexibility  is  de¬ 
mand  printing. 
Adequate  demand 
printing  support 
at  tiers  3  and  4  is 
critical  to  the  suc¬ 
cess  of  AFTOMS. 

Given  the  POC 
work,  this  section 
assesses  demand 
printing  issues. 


STATE  OF  THE  TECHNOLOGY 


By  acquiring  TOs  in  digital  form  and  manipulating  their  digital  representa¬ 
tion,  the  decision  of  when  and  what  to  print  on  demand  becomes  an  eco¬ 
nomic  and  operational  one,  rather  than  a  technological  decision. 

Computer-based  printing  devices  are  generally  divided  into  two  categories: 
impact  primers  and  non-.dr.pact  primers.  Impact  printers,  which  include 
dot  matrix  and  daisy  wheel  printers,  produce  the  punted  character  on  the 
paper  through  direct  contact.  In  general,  impact  primers  have  limited 
graphics  capability,  which  is  a  critical  shortcoming  for  AFTOMS,  and  pro¬ 
duce  lower  quality  print  than  non-impact  primers.  In  addition,  since  impact 
printing  involves  the  coming  together  of  paper,  ribbon  and  molded  charac¬ 
ters,  the  printing  speed  is  much  slower,  and  as  such  will  not  provide  the 
necessary  throughput  for  TO  operations. 

Non-impact  printers  use  electrostatic  forces  to  form  a  full-page  bit¬ 
mapped  image  from  digital  information  and  then  transfer  that  image  io  the 
page  using  toner  and  heat.  Such  printers,  which  can  be  implementations  of 
several  physical  principles,  offer  higher  speeds  and  lower  noise  levels  than 
impact  printers.  One  disadvantage  of  non-impact  printers  is  that  they  can 
prim  only  one  copy  at  a  time  whereas  impact  printers  can  print  multiple 
copies  simultaneously.  A  need  for  multiple  copies  makes  it  necessary  to 
repeat  the  printing  cycle  many  times  when  using  a  non-impact  printer. 

This,  however,  should  not  be  a  problem  for  AFTOMS  since  demand  print¬ 
ing  is  usually  single  copy  oriented. 

Non-impact  primers  require  a  Page  Description  Language  (PDL)  to  tell  the 
printer  what  information  to  print,  where  to  print  it  on  the  page,  and  what 
special  effects  to  produce.  A  PDL  uses  mathematical  descriptions  of  graph¬ 
ic  and  symbolic  elements  to  compose  a  page  containing  images,  allow  mix¬ 
ing  of  text  and  graphical  elements  on  the  same  page,  and  print  a  document 
at  various  resolutions  on  different  quality  primers  without  modifying  the 
document. 

All  non-impact  printers  are  rated  by  the  pages  which  can  be  processed  by 
their  imaging  equipment.  The  throughput  is  a  function  of  how  quickly  the 
supporting  processing,  which  is  the  current  limitation,  can  render  the  image 
from  the  incoming  PDL  file.  For  example,  affordable  laser  printers  now 
offer  6— to— 3 2  pages  per  minute  at  3QO-KMQO  dpi  resolution. 

FY91-FV93: 

Technology  will  provide  faster  printer  throughput  by  processing  PDL  with 
more  powerful  and  faster  processors.  This  will  allow  throughput  to  ap¬ 
proach  the  speed  ratings  of  the  hardware  imaging  devices.  Developing  PDL 
standards  will  probably  converge  around  a  superset  of  PostScript,  the  cur¬ 
rent  de  facto  standard.  Increasing  numbers  of  primer  manufacturers  will 
support  PostScript  because  of  user  demand,  while  PostScript  interpreter 
“clones”  will  evolve  as  alternatives.  This  will  stimulate  PostScript  perform¬ 
ance  gains.  High  speed  printers  using  Ionography  will  become  more  nu- 
merous.  reducing  printing  costs  due  to  the  reliability  of  the  technology  . 


TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT'D) 


INDIVIDUAL 
TECHNOLOGY 
T9  (CONT’D) 


DEMAND 

PRINTING 


FY91-FY93  RISK 


LEGEND 

RISK  ASSESSMENT 
SYMBOLS- 

■  HIGH 


MEDIUM 


LOW 


ASSESSMENT 


Graphical  printing  technologies  are 
mature,  having  been  in  wide 
commercial  acceptance  for  over  five 
years.  Early  difficulties  have  been 
overcome  and  the  present  genera¬ 
tion  of  laser  hardware  and  driving 
software  is  noted  for  reliability  and 
proven  performance.  The  current 
typical  300-to-600  dpi  output  quali¬ 
ty  is  sufficient  for  AFTOMS  pur¬ 
poses.  There  is  little  technologica1 
risk  associated  with  the  printing 
resources  selected.  Other  residual 
risks  ire  present  in  the  following 


Priming  capacity  will  not  be  ade¬ 
quate  ly  matched  to  needs. 


Printer  unreliability  can  degrade 
AFTOMS  productivity. 


ABATEMENT 


The  Air  Force  could  abate  these 
risks  by: 


DoD  and  the  Industry  at  large  are 
converging  on  a  new  Standard 
Page  Description  Language 
(PDL)  which  could  require  con¬ 
version  of  previously-encoded 
PDL  digital  files. 


□  Developing  a  planning  and  sizing 
tool  to  define  printing  resources 
required  for  any  TOMA  TOC, 
CTO  DO,  or  WA  installation 
based  on  its  profile  and  volume  of 
AFTOMS  work.  Printing  re¬ 
sources  are  essentially  modular  in 
nature  and  their  capacities  addi¬ 
tive,  as  entire  printers  can  be 
moved  from  one  computer  to 
another  m  response  to  user  de¬ 
mands  or  to  equipment  downtime. 
Additional  printers  can  be  ac¬ 
quired  as  priming  requirements 
increase. 

f~1  The  risk  of  laser  primer  failure  in 
service  is  minimal,  and  recovery 
from  failure  straightforward. 
Repair  is  typically  by  a  specialist 
and  involves  board  changes — a 
task  similar  to  copier  service. 
Expendable  spares  such  as  toner 
cartridges  and  paper  must  be  kept 
on  hand  and  are  user  installable. 
The  large  established  user  com¬ 
munity  will  lead  vendors  to  main¬ 
tain  stocks  of  these  expendable 
items  for  the  foreseeable  future. 


PostScript  is  likely  to  remain  the 
de  facto  PDL  standard  for  conve¬ 
nience  laser  primers.  As  Post¬ 
Script  evolves  into  or  is  replaced 
by  the  Standard  PDL  of  the  future 
it  is  expected  that  a  converter  or 
translater  will  be  made  available 
to  automatically  translate  Post¬ 
Script  encoded  files  to  the  Stan¬ 
dard  PDL 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT'D) 


T10  INDIVIDUAL 

TECHNOLOGY 


WORKSTATION 

PLATFORMS 

RELEVANCE: 

AFTOMS  uses  so¬ 
phisticated  publi¬ 
cation  SW  (which 
requires  integrated 
display  and  process¬ 
ing  of  text  &  graph¬ 
ics)  for  authoring, 
tagging,  change 
processing,  and 
verifying  TOs;  also, 
AFTOMS  needs 
X -window  based 
graphical  user  in¬ 
terfaces  to  inte¬ 
grate  diverse  tech¬ 
nology  products, 
make  AFTOMS 
easier  to  use,  and 
able  to  run  on  het¬ 
erogeneous  HW 
platforms.  These 
requirements  make 
character-oriented 
displays  unaccept¬ 
able,  and  high- 
performance,  bit¬ 
mapped  graphic 
workstations  a  key 
technology  for 
processing  TOs. 

Given  the  POC 
work,  this  section 
assesses  worksta¬ 
tion  platform 
|  technology. 


STATE  OF  THE  TECHNOLOGY 


FY89: 


AFTOMS  functional  requirements  make  character-oriented  displays  unac¬ 
ceptable;  and  high-performance,  high-resolution,  bit-mapped  graphic 
workstations  the  fundamental  technology  for  processing  and  displaying 
TOs.  All  engineering  workstations  and  most  sophisticated  personal  com¬ 
puter  applications  are  also  moving  away  from  character-oriented  disriav 
systems  and  implementing  graphical  user  interfaces  based  on  windowing 
software  (e.g.,  the  X-window  standard). 

Workstations,  originally  called  engineering  workstations,  emerged  as  a  new 
hardware  technology  in  the  early  1980's  as  an  outgrowth  of  the  engineering 
design  and  manufacturing  community.  These  platforms  offer  high-speed 
processing  and  graphics,  and  large  memory  and  hard  disk  capacities  to  store 
memory-intensive  graphics.  Early  workstations  did  not  support  common 
standards  (e.g.,  UNIX,  X-window,  TCP/IP,  etc.),  but  were  based  on  propri¬ 
etary  operating  systems  and  protocols  to  support  specialized  application 
activities.  With  more  sophisticated  users  and  software  applications  compet¬ 
ing  in  the  market  the  workstation  trend  now  is  toward  open  architectures 
and  support  of  standards. 


With  the  advent  of  new  architecture  microprocessors,  workstation  perform¬ 
ance  has  increased  dramatically  making  real-time  graphics  available  on 
most  workstations.  Currently,  competitively-priced  workstations  generally 
process  more  than  5  million  instructions  per  second  (MIPS),  support  1-2 
megapixel  displays,  contain  4-32  megabytes  of  memory,  have  gigabytes  of 
diskspace,  support  multiple  users  and  concurrent  processing,  and  provide 
LAN  access.  This  workstation  techno!-  >gy  is  primarily  aimed  at  supponuig 
engineering  and  publication  applications,  with  growing  but  still  limited  sup¬ 
port  in  other  application  areas  (e.g.,  DBMS,  spreadsheet,  and  management 
applications).  These  workstations  can  support  AFTOMS  requirements  now 
although  faster  graphics  processing  would  benefit  user  productivity. 


FY91-FY93:  ) 

Workstations  will  continue  to  increase  in  performance  and  decrease  in  price 
over  the  next  5  to  8  years.  It  is  expected  that  in  FY93  commercially- 
available  workstations  will  process  at  speeds  up  to  100  MIPS,  have  50-75 
megabytes  of  memory,  support  2-4  megapixel  displays,  and  have  fast  access 
erasable  optical  disk  drives  containing  400+  megabytes  of  disk  space.  At 
the  low  end,  5  MIPS  workstations  should  be  between  $5,000  -  $10,000  by 
FY93;  such  workstations  will  also  have  dedicated,  enhanced  (32-bit,  16 
MHz)  graphics  co-processors,  and  high-performance  (32-bit,  20  MHz) 
input/output  (I/O)  co-processors.  The  limiting  factor  for  workstation  tech¬ 
nology  growth  is  the  expected  development  of  inexpensive  fast  memoiy. 


3-26 


3-27 


TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


XI 1  INDIVIDUAL 

TECHNOLOGY 


DOCUMENT  B+ 
ENHANCEMENTS 


RELEVANCE: 

Type  B  TOs  are 
digital,  electroni¬ 
cally-stored,  fully 
editable,  page- 
based  documents. 
Type  B  +  is  an  en¬ 
hanced  version  of 
Type  B;  in  a  gener¬ 
al  sense,  the  B-F 
extensions  to  B  are 
defined  as  those 
extensions  that 
provide  all  the 
TO-related  func¬ 
tionality  envi¬ 
sioned  for  a  Type  C 
system,  except 
storage  of  the  data 
in  neutral  form. 

Given  the  POC 
work  which  incor¬ 
porated  several 
B+  capabilities 
into  the  Demo  Sys¬ 
tem,  this  section 
assesses  possible 
B+  capabilities, 
their  relationship 
to  a  Future  Type  C 
approach,  and 
technologies  need¬ 
ed  to  provide  B  -f 
funetionality. 


STATE  OF  THE  TECHNOLOGY 
FY89:  | 

B  +  enhancements  are  defined  to  encompass  the  following  functionality: 

■  Use  (at  Tier  4)  customized  views,  branching  logic  and  referential 
links,  custom  work  packs,  synchronized  text  and  figure  viewing,  and 
links  from  specific  TO  positions  to  external  systems  and  databases; 

■  Cataloging:  ability  to  enter  and  retrieve  management  information 
about  TOs  below  the  TO  level,  Le.,  cataloging  and  indexing  of  TO 
subject  matter,  including  related  material  across  TOs  especially  rcr 
purposes  of  controlling  changes  to  related  sections;  and 

■  Document  Component  Management:  management  of  components 
of  like  material  that  are  shared  across  multiple  TOs,  including 
management  of  changes  to  those  components. 

Type  C  also  provides  such  functionality  and  conceptually  is  far  better 
suited  than  Type  B+  for  handling  the  integration  of  all  types  of  technical 
data.  However,  Type  C  operational  requirements  for  AFTOMS  and  the 
avaiiabi'ity  of  technologies  to  support  them  need  to  be  investigated  fur¬ 
ther.  Type  B  +  is  understood  well;  requires  few  process  changes  over  Type 
B,  mostly  involving  the  addition  of  a  ft  w  more  tags  to  Type  B  data  and 
some  additional  sophisticated  software;  and  commercial  technologies  are 
becoming  available  to  support  B  +  for  AFTOMS  deployment.  The  Type  C 
storage  of  data  in  neutral  (rather  than  document)  form  significantly  impacts 
the  design  of  AFTOMS,  which  must  then  accomodate  several  data  models. 
Several  different  technologies,  established  or  emerging  in  FY89,  can  be 
applied  to  support  B+  capabilities,  including:  Hypertext,  Relational  data¬ 
bases,  Object-oriented  databases,  Hypermedia  information  servers.  Full- 
text  retrieval  systems,  On-line  Delivery  Systems,  Page  Previewers,  and 
Document  Management  Systems.  Product  integration  is  in  progress,  and  it 
is  anticipated  that  many  of  these  technology  products  will  be  better  inte¬ 
grated  within  the  next  one  to  two  years.  By  then,  these  products  will  also 
be  much  more  mature  operationally.  The  areas  of  highest  risk  include  doc¬ 
ument  conversion  (see  T16),  tagging,  and  management  of  changes. 

Using  today’s  technology,  the  tagging  process  can  only  be  automated  in  a 
limited  way.  Isolation  of  simple  structural  elements  such  as  paragraphs  is 
within  range  of  “auto-tagging”  software,  but  recognition  of  complex  table 
cells  with  embedded  graphics,  spanning  heads,  etc.  is  not  automated. 
Document  component  management  is  a  complex  area  especially  regarding 
management  of  changes  to  shared  variable  components.  These  components 
are  somewhat  difficult  to  isolate  from  the  surrounding  text,  and  also  diffi¬ 
cult  to  manage  once  they  are  created.  DMS  products  are  beginning  to  deal 
with  this  problem,  but  they  have  a  way  to  go  toward  a  complete  solution. 
The  other  areas  of  B+  functionality  such  as  cataloging  and  customized 
display  at  Tier  4  are  well  within  the  capabilities  of  current  technology. 


The  cited  technologies  are  expected  to  develop  sufficiently  by  this  time  to 
allow  implementation  of  a  useful  B+  capability,  which  can  be  expanded 
logically  and  in  stages  as  needed  based  on  the  operational  experience  of  a 
fielded  AFTOMS.  Limitations  and  risks  are  noted  on  the  following  page. 
An  AFTOMS-integrated  operational  Type  C  capability  will  be  difficult  to 
achieve  in  this  timeframe  (see  TABLE  2-1.  B2). 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT'D) 


T12  INDIVIDUAL 

TECHNOLOGY 


SOFTWARE 
DESIGN  / 

IMPLEMENTATION 

LANGUAGES 


RELEVANCE: 

AFTOMS  will  be 
developed  by  seam¬ 
lessly  integrating 
several  large-scale, 
commercially  de¬ 
veloped,  state-of- 
the-art  systems 
that  individually 
exploit  particular 
technologies  and 
focus  on  specific 
areas  of  function¬ 
ality. 

Given  the  POC 
work,  this  section 
assesses  software 
design  and  imple¬ 
mentation  issues 
to:  successfully  ac¬ 
complish  this  inte¬ 
gration  to  build  a 
productive  TO  sys¬ 
tem;  and  provide 
the  necessary  de¬ 
sign  flexibility  to 
support  long-term 
objectives  of  lower 
lifecvcle  costs  for 
AFTOMS  and 
CALS  interoper¬ 
ability^ _ 


STATE  OF  THE  TECHNOLOGY 


FY89: 


Software  development  is  bedeviled  by  complexity';  this  is  seen  in  the  ever 
increasing  size  and  complexity  of  the  problems  it  is  being  asked  to  solve  as 
well  as  in  the  proliferation  and  complexity  of  the  tools  it  has  to  solve  them 
with.  Furthermore,  because  of  the  interoperability  trend  toward  integrating 
systems  to  make  their  functionality  and  data  more  useful  as  well  as  the  in¬ 
teractive  nature  of  each  system  internally,  complexity  increases  much  more 
rapidly  than  system  size  alone  might  suggest.  AFTOMS  exhibits  these  char¬ 
acteristics  and  so  will  be  a  complex  system  to  develop  well.  Drawing  on 
successful  concepts  and  results  from  mathematics,  engineering,  manage¬ 
ment  science,  psychology,  and  real-world  experience,  software  engineering  I 
principles  have  been  developed  and  should  be  used  to  develop  AFTOMS; 
these  principles  are  being  incorporated  into  modem: 

■  Design  techniques; 

"  Programming  languages;  and 

■  Development  environments. 

Object-oriented  design  methodology  best  embodies  and  enforces  the  entire 
set  of  software  engineering  principles.  Tools  are  becoming  available  to  sup¬ 
port  modem  design  methodologies.  Prototyping  is  an  important  supple¬ 
mentary  dynamic  design  too!  that  is  useful  for  improving  system  require¬ 
ments  and  design  quality,  and  is  particularly  valuable  for  complex  systems 
with  breakthrough  functionality. 

Available  programming  languages  incorporate  varying  degrees  of  software 
engineering  principles,  including  object-orientation.  Most  of  the  commer¬ 
cial  technology  products  that  AFTOMS  will  consider  for  integration  prob¬ 
ably  will  have  been  written  in  either  the  C  or  C  +  +  language;  and  C+  + 
is  a  suitably  enhanced,  compatible  alternative  for  C.  Therefore,  use  of  these 
languages  plus  SQL  for  database  access,  and  others  for  their  domain  of  spe¬ 
cialization  (e.g.,  PDL  for  printing),  could  ease  initial  integration  and  offer 
lifecycle  maintainability  benefits. 

Development  environments  help  enforce  standardization  and  increase  de¬ 
velopment  productivity  by  providing  automated  support  Tools  for  express¬ 
ing  object-oriented  designs  are  emerging  so  this  technology  is  not  yet  ma¬ 
ture.  Because  of  DoD  support,  ADA-based  tools  are  most  appropriate  and 
adequate  enough  to  design  large-scale  systems.  For  example,  ADA  tools 
have  been  used  to  design  systems  that  were  ultimately  coded  in  C,  JO¬ 
VIAL  ADA  ar.d  even  Assembly  Language.  The  FY89  prototyping  activity 
didn’t  require  a  formal  MIL-STD-compliant  development  environment  so 
it  was  carried  out  informally. 


FY93-FY93: 

The  maturity  of  the  object-oriented  design  technology,  wider  availability  of 
tool  sets  and  language  implementations,  and  emphasis  on  integrating  them 
should  adequately,  if  not  optimally,  support  the  design  and  implementation 
needs  of  the  actual  AFTOMS  system  using  either  ADA  or  C  +  ,  given: 

■  The  current  activity  in  the  object-oriented  market  (for  design 
methodologies,  languages,  and  development  environments); 

■  DoD’s  commitment  to  software  engineering;  and 

■  Increasing  use  of  these  technologies  in  text  and  graphics  based 
applications. 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT'D) 


X13  INDIVIDUAL 

TECHNOLOGY 

STATE  OF  THE  TECHNOLOGY 

GOVERNMENT 

DATA 

INTERCHANGE 

STANDARDS 

RELEVANCE: 

Conceptually,  the 
AFTOMS  model  is 
simply:  Create, 
Manage,  and  Use 
TOs.  TOs  are 
created  primarily 
by  contractors; 
whereas,  they  are 
managed  in  the  AF 
bv  AFLC/MM. 
MIL-STD-1840  is 
the  only  interface 
between  these  acti¬ 
vities.  It  brings 
standardization, 
consistency,  and 
discipline  to  teth 
the  TO  product 
and  the  processes. 
Without  the 
successful  imple¬ 
mentation  of  this 
standard  input- 
side  interface,  AF¬ 
TOMS  cannot 
succeed. 

Given  the  POC 
work,  this  section 
assesses  the  tech¬ 
nology  needed  to 
implement  the  au¬ 
tomated  solutions 
for  .his  interface. 

FV  89: 

Even  though  the  CALS  Initiative  began  in  FY86,  very  little  operational 
software  to  support  CALS  exists  in  industry.  Early  on.  industry  was  not 
sure  of  the  direction  of  the  program,  nor  were  there  any  approved  or  stable 
specifications  to  build  products  against.  This  was  especially  true  in  the 
MIL-STD  1840  and  SGML  areas.  In  FY88.  CATS  momentum  increased 
dramatically  which  stimulated  industry  vendors  suppliers  to  participate  sig¬ 
nificantly  in  the  various  standards  committees  (to  define  and  build  consen¬ 
sus  for  detailed  specifications)  and  u>  begin  product  development.  While 
the  specifications  are  far  from  complete,  significant  product  development 
occurred  in  FY88  and  FY89.  culminating  with  several  initial  versions  of 
MIL-STD  1840  and  SGML  products.  CALS-comphant  It)  products  fall 
mainly  into  three  categones: 

■  CALS  Support  Package: 

■  Productivity  Tools;  and 

■  Integrated  CALS  TO  System. 

In  the  CALS  Support  Package  category,  most  of  the  products  (both  standa¬ 
lone  and  embedded)  offer  significant  functionality  for  MIL-STD-1840  Tape 
Generation  and  Tape  Processing  even  though  they  are  only  first  or  second 
releases.  Interactive  S^ML  Editing  functionality  is  not  nearly  as  far  along 
Very  few,  if  any.  production-quality  products  exist  today;  however,  several 
pre-release  products  have  surfaced  with  announced  product  availability 
dates  in  FY89-FY90.  Smaller  software  companies  are  producing  many  of 
the  specific  integrated  modules  (e  g.,  an  SGML  parser);  whereas,  large 
publishing  vendors  are  producing  solutions  with  embedded  CALS  support. 

In  the  Productivity  Tools  category,  a  significant  numbe:  of  such  tools  (both 
standalone  and  embedded)  are  entering  the  marketplace  in  FY89-FY90. 
Many  of  these  tools  exist  on  personal  computers  (PCs)  and  are  being  mi¬ 
grated  to  larger  micro  and  mini-computer  based  publishing  systems.  While 
the  availability  of  individual  tools  is  plentiful,  they  have  only  marginal  use 
at  this  time  because  of  integration  deficiencies  requiring  manual  interven¬ 
tion.  If  they  can  be  linked  to  the  previous  and  succeeding  automated  steps 
in  the  TO  process,  their  value  increases  greatly.  In  the  Integrated  CALS 

TO  System  category,  this  capability  is  essentially  nor.  existent  in  TVS?. 

Some  integration  has  been  accomplished  across  a  few  areas,  but  more  im¬ 
portantly.  all  of  the  large  vendors  and  system  integrators  recognize  the  val¬ 
ue  and  need  to  link  these  supporting  technologies.  In  summary,  while 
much  progress  has  been  made  over  the  past  two  years,  available  products 
cannot  be  used  in  a  production  environment  due  to  lack  of  adequate  test¬ 
ing,  minimal  integration  of  the  component  modules,  and  lack  of  well  de¬ 
fined  MTI  -STD-1R40  DTDs  and  Ontnnt  Sners. 

FY91-FY93: 

The  outlook  for  availability  of  integrated  solutions  for  TOs  in  this  time 
frame  looks  very  promising  for  the  foliowing  reasons: 

■  CALS  growing  momentum  and  acceptance  in  industry; 

■  Transferability  of  products  developed  for  CALS  to  other  sectors; 

■  Assistance  of  CALS  Test  Network  (CTN)  for  testing;  and 

■  Track  record  of  electronic  publishing  industry  during  FY83-FY89 
indicate*  ability  to  produce  AFTOMS  solutions  by  FY93 
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INDIVIDUAL 
TECHNOLOGY 
T13  (CONT’D) 


GOVERNMENT 

DATA 

INTERCHANGE 

STANDARDS 


FY91-FY93  RISK 


LEGEND 


RISK  ASSESSMENT 
SYMBOLS. 

■  HIGH 


MEDIUM 


ASSESSMENT 


MIL-STD  1840  has  been  designated 
as  (he  only  standard  for  digital  de¬ 
livery  of  TOs  to  DoD  from  the  con¬ 
tractor.  The  software  products  that 
support  automated  preparation  and 
acceptance  of  TOs  in  digital  form 
are  vitally  important  to  the  success 
of  this  data  interchange  standard. 
These  products  will  be  used  io  ac¬ 
cept  converted  as  well  as  newly 
created  TOs  into  AF  inventory. 
Without  these  products  it  will  be  im¬ 
possible  to  load  the  AFTOMS  data¬ 
base  and  shift  over  to  digital  opera¬ 
tions  (i.e.,  distribution,  repositing. 
demand  printing,  change  manage¬ 
ment).  These  products  need  to  be 
considerably  along  in  their  product 
di  velopment  cycle  to  mesh  with  the 
Al  IOMS  deployment  schedule.  Re¬ 
sidual  risks  are  present  in  the  fol¬ 
lowing  areas: 

5  The  biggest  asks  in  TO  data  inter¬ 
change  he  tn  two  areas:  availability 
of  DTDs  and  Output  Specs  (OSs); 
and  thorough  conformance  and 
performance  testing  of  this  inter¬ 
face  and  its  associated  operational 
procedures  so  contractors,  ven¬ 
dors.  and  AFTOMS  devel-pers 
have  full  confidence  m  the  com¬ 
ponent  parts  of  the  solution. 

^  Vendor-achieved  integration  of 
I  CALS  product  offerings  (which 
—1  are  needed  for  AFTOMS)  may  be 
more  partial  than  expected  when 
deployment  of  AFTOMS  begins. 


Slower  than  predicted  progress  in 
developing  and  marketing  usefully 
integrated  productivity  tools. 


Interactive  SGML  Editing  func¬ 
tionality  may  not  be  mature  and 
robust  enough. 


ABATEMENT 


The  Air  Force  could  abate  these 
risks  by: 

r-j  Progress  in  both  of  these  areas  ha^ 
been  proceeding  at  a  very  slow 
pace.  AF  should  work  to: 

■  Complete  the  D'lTk  cur¬ 
rently  in  development; 

•  Develop  companion  OSs  for 
DTDs  (including  both  paper 
and  display  output  ); 

"  Test  the  data  interchange  in¬ 
terface  with  these  specs;  and 

■  Develop  the  DTDs  OSs  for 
Type  C  TO  data. 

f~l  IFie  Integrated  CALS  TO  solu¬ 
tion  is  complex  and  not  far  along 
While  large-scale  publishing  solu¬ 
tion  vendors  are  beginning  to 
work  this  problem,  it  is  difficult  to 
predict  hiiw  much  progress  will  be 
made  in  the  next  few  years.  The 
ask  here  is  more  one  of  timing 
than  technology.  However,  by  the 
end  of  the  deployment  period,  this 
capability  should  be  available  for 
production  use.  Work  closely 
with  vendors  to  make  this  happen 

□  Productivity  tools  will  continue  to 
become  available  in  increasing 
numbers  over  the  next  few  years 
to  reduce  the  labor  intensive  na¬ 
ture  of  the  processing  and  reduce 
the  asks  in  digital  exchange  of 
TOs.  Slower  progress  in  this  area 
will  not  be  catastrophic,  but  rather 
will  make  this  processing  less  effi¬ 
cient.  Select  specific  tools  and 
work  with  yendors  to  improve 
them. 

0  Interactive  SGML  Editing  func¬ 
tionality  ls  in  the  process  of  being 
added  to  many  systems  in 
FY89-FY90  and  should  be  avail¬ 
able  in  operational  form  when 
needed.  W'ork  with  vendors  to 
make  this  happen. 
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J14  INDIYIDUAL 

TECHNOLOGY 

STATE  OF  THE  TECHNOLOGY 

DE  FACTO  and 

DE  JURE 
COMPUTER 
INDUSTRY 
STANDARDS 

RELEVANCE: 

A  long-lifecycle, 
integrated  HW- 
SW  system  such  as 
AFTOMS  is  helped 
tremendously  by 
the  choice  and  im¬ 
plementation  of 
standards  for:  ease 
of  integration  dur¬ 
ing  development; 
better  quality:  and 
lower  cr~*  of  main¬ 
tenance  (which  in¬ 
cludes  correcting 
problems,  enhancing 
existing  or  adding 
new  functionality, 
avoiding  obsoles¬ 
cence,  and  upgrad¬ 
ing  operational 
performance). 

Given  the  POC 
work,  this  section 
provides  the  basis 
for  identify  ing  and 
understanding  the 
AFTOMS-relevant 
computer  industry 
standards:  their 
scope,  current 
state,  interdepen¬ 
dence  with  other 
standards,  and 
likely  evolution. 

FY89: 

Standards  are  neither  preordained,  nor  static,  nor  free  of  conflict  and 
tradeoffs.  In  fact,  their  development  and  acceptance  is  quite  frustrating  and 
messy.  The  end  result  is  rarely  final  or  fully  satisfactory,  but  they  are  nec¬ 
essary  to  reduce  complexity  to  manageable  proportions  and  support  inter¬ 
dependencies  in  and  between  organizations,  people,  information  handling, 
software  systems,  and  hardware  equipments. 

Standards  rarely  precede  an  important  technology  That's  because  the  im¬ 
portance  of  the  technology  and  its  many  applications  is  difficult  to  gauge  at 
the  outset,  and  there  are  usually  alternative  variants  of  the  technology  be¬ 
ing  developed,  each  with  its  own  unique  mix  of  virtues  and  problems.  Pre¬ 
mature  standardisation  can  misdirect  the  development  of  the  technology 
onto  an  unproductive  path.  Sometimes  this  risk  must  be  taken  if  there  i> 
an  overriding  dimension  to  the  technology  (e.g.,  safety,  total  compatibility 
for  market  acceptance,  etc.);  but  for  most  technologies  this  is  not  the  case. 

As  a  technology  develops,  the  proponents  of  its  variants  establish  different 
degrees  of  acceptance  for  various  uses.  This  gets  reflected  in  the  market 
success  of  individual  companies  or  product  categories.  If  one  technology 
variant  becomes  dominant  in  acceptance  (e.g..  PostScript  in  device-inde¬ 
pendent  Page  Description  Languages  for  integrated  text -graphics  printing), 
then  that  variant  becomes  a  de  facto  standard  for  that  technology:  most 
users  demand  it.  and  new  competitors  don't  want  to  deviate  too  far  from  it 
and  risk  market  failure.  A  de  facto  standard  will  evolve  over  time  as  the 
technology  ts  refined  and  usage  is  modified.  De  facto  technology  standards 
(which  represent  the  actual  core  of  the  technology  without  having  any  legal 
standing)  are  relatively  easy  to  transform  into  de  jure  technology  standards 
(which  enjoy  a  legal  standing)  because  the  technology  is  reasonably  well 
understood,  there  are  entrenched  groups  of  users  and  providers  who  don't 
want  major  disruptions,  and  there  is  relatively  little  disagreement  on  the 
important  aspects  of  the  technology.  DoD  and  AF,  as  important  active  us¬ 
ers  (technically,  legally,  and  financially)  of  technology  products,  can  influ¬ 
ence  standards  of  either  standing.  For  the  foreseeable  future,  technology 
standards  will  continue  to  be  developed  and  amended  using  this  basic  ap¬ 
proach;  the  design  of  AFTOMS  should  reflect  this  reality. 

Twenty  Nine  (29)  major  standards  expected  to  be  relevant  to  AFTOMS  in 
FY91-FY93  were  evaluated  using  the  following  common  template: 

■  Identifier  (name,  #,  sponsoring  org.  &  last  issue  date); 

■  Capsule  Summary  of  the  Standard; 

■  Its  relevance  &  importance  to  AFTOMS; 

■  Its  state  (usefulness,  completeness,  stability): 

in  FYS9;  and  by  FY91-FY93. 

Nineteen  D9)  of  these  standards  were  also  used  in  the  Demo  Svstem. 

FY91-FY93: 

Rather  than  summarize  the  states  of  each  of  these  29  standards,  many  of 
which  present  no  significant  risks  for  AFTOMS,  only  the  problematic  stan¬ 
dards  are  categorized  and  listed  on  the  next  page. 
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T15  INDIVIDUAL 

TECHNOLOGY 


TRAINING 
TECHNOLOGIES 
and  AFTOMS 
ASSIMILATION 


RELEVANCE: 

In  the  past  ten 
years,  major  ad¬ 
vancements  in 
training  technolo¬ 
gies  have  occurred 
which  can  benefit 
AFTOMS.  Some 
of  the  potential 
benefits  include: 
reduced  training 
time,  fewer  re¬ 
quired  training  re¬ 
sources,  increased 
trainee  achieve¬ 
ment,  lower  attri¬ 
tion  rates,  and  in¬ 
creased  job  profi¬ 
ciency. 

Given  the  POC 
work,  this  section 
assesses  the 
AFTOMS  rele¬ 
vance  of  two  major 
areas  of  training; 
HYV-SW  training 
technology  and  its 
underlying  train¬ 
ing  methodology. 
No  specific  train¬ 
ing  products  were 
incorporated  into 
the  Demo  System. 


STATE  OF  THE  TECHNOLOGY 


Training  technology  risk  assessment  was  not  within  the  original  scope  of 
the  FY89  AFTOMS  POC  efTort  undertaken  at  TSC  so  the  POC  did  not  in¬ 
clude  the  investigation  of  actual  training  technology  products.  Therefore,  a 
detailed  assessment  of  training  technology  risks  was  not  undertaken  and 
will  need  to  be  done  by  the  AFTOMS  SPO  before  FY91.  However,  since 
the  POC  work  touched  on  issues  that  would  also  impact  training,  the 
following  preliminary  assessment  of  training  risks  was  made. 

In  FY89,  there  are  many  recently  introduced  technologies  that  appear  to 
have  unique  training  capabilities.  Some  of  the  key  functionality  that  has 
been  introduced  recently  includes: 

■  More  interactive  training  capabilities  through  the  use  of  videodisc 
and  hypermedia; 

■  The  ability  to  easily  combine  documents,  images,  video  playback, 
voice,  and  system  processes; 

■  Self  learning  packages  that  can  be  monitored  and  evaluated  for 
changes; 

■  Communications  capabilities,  such  as  telecommunications,  that 
allow  easy  access  to  distributed  resources  and  facilitate  the 
distribution  of  knowledge; 

■  Use  of  the  existing  large  distributed  base  of  personal  and  micro 
computers  for  training  purposes;  and 

■  New  networking  capabilities  for  sharing  training  materials  across 
the  network. 

The  DoD  has  a  long  history  of  pioneering  new  technologies  for  training  its 
personnel.  Trainers  have  become  more  familiar  with  new  training  technolo¬ 
gies  and  are  beginning  to  use  them  more  frequently  in  the  development  of 
training  curricula.  As  technology  costs  decrease  and  such  experience  in¬ 
creases,  more  information  will  be  available  about  technology  potential,  ap¬ 
plicability,  and  effectiveness  for  training.  The  cost  of  computer  equipment 
and  software  is  also  declining.  This  should  have  a  direct  impact  on  the  in¬ 
creased  use  of  computer  technology  in  the  training  community. 

FY91-FY93: 

The  use  of  technology  in  training  will  continue  to  mature  and  improve  in 
performance  and  cost.  As  computers  continue  to  become  more  powerful, 
they  will  incorporate  and  integrate  more  functionality  into  a  single  training 
program. 

Training  technologies  also  appear  to  be  increasing  their  emphasis  on  inter¬ 
active  training.  With  the  introduction  of  videodiscs  and  hypertext  media  in 
the  1980's,  it  appears  possible  for  users  to  interact  in  a  more  realistic  man¬ 
ner  w-ith  training  materials.  Use  of  remotely  located  experts  to  solve  specific 
training  issues  will  also  increase  as  telecommunications  continues  to  evolve, 
standards  are  established,  and  costs  become  acceptable. 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


INDIVIDUAL 
TECHNOLOGY 
T15  (CONT’D) 


FY91-FY93  RISK 


ASSESSMENT 


ABATEMENT 


TRAINING 
TECHNOLOGIES 
and  AFTOMS 
ASSIMILATION 


Training  Air  Force  personnel  in  the 
use  of  AFTOMS  is  essential  to  the 
success  of  the  overall  program.  The 
POC  has  shown  that  simple,  friendly 
user  interfaces  help  users  quickly 
assimilate  the  functionality  of  the 
overall  system  with  less  initial  and 
followup  training.  By  standardizing 
the  ’’look  and  feel”  of  AFTOMS 
user  interfaces  across  all  four  tiers 
in  the  POC  it  became  simpler  for  a 
Tier  2  user  to  understand  how  to 
use  Tier  4  functionality.  In  terms  of 
training  impacts  for  AFTOMS, 
there  are  several  residual  risks  to 
avoid: 

BThe  design  of  the  AFTOMS  func¬ 
tionality  and  user  interface  is  so 
unwieldy  that  it  slows  down  (or 
even  jeopardizes)  productive  use 
of  AFTOMS,  whether  users  re¬ 
ceive  comprehensive,  quality 
training  or  not. 


During  or  before  the  FY91-FY93 
AFTOMS  development  period,  the 
Air  Force  could  abate  the  risks  by 
exploring  more  thoroughly  the  fol¬ 
lowing  strategies: 


Users  should  have  input  into  AF¬ 
TOMS  design  at  the  earliest  time 
possible.  The  POC  Demo  System 
could  be  used  in  this  manner 
various  users  could  be  allowed  to 
interact  with  the  Demo  System, 
explore  its  capabilities  dynamical¬ 
ly,  and  give  constructive  feedback 
Co  designers.  This  would  also  help 
build  early  support  for  AFTOMS 
with  actual  users. 


LEGEND 


RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


Training  costs  become  prohibitive 
for  a  large  system  if  specialized 
training  is  needed  for  each  indi¬ 
vidual  user,  if  AFTOMS  is  not  de¬ 
signed  and  implemented  using  a 
standard  interface  approach,  it 
will  require  individual  and  costly 
training  design  and  implementa¬ 
tion. 


The  time  needed  for  comprehen¬ 
sive  training  detracts  from  the 
productivity  of  the  users  on  tasks 
they  are  presently  responsible  for. 


A  standard  and  consistent  user  in¬ 
terface  design  should  be  devel¬ 
oped  for  all  the  tiers.  This  will 
promote  easier  use  of  the  system 
and  facilitate  a  group  approach  to 
the  training  design.  Then,  a  basic 
core  training  package  could  be  de¬ 
signed  for  all  the  users,  supplem¬ 
ented  with  smaller  specialized 
packets  for  each  tier. 


The  training  curriculum  should  be 
modularized  to  reduce  extended 
absences  from  existing  tasks  for 
AFTOMS  training.  Shorter  train¬ 
ing,  based  on  self-learning  CBI 
software  using  videodisc  technolo¬ 
gy,  could  be  employed.  Training 
time  can  also  be  reduced  by  using 
focused  Job  Ads  such  as  on-line 
help  or  teleconferencing  to  desig¬ 
nated  AFTOMS  user  experts. 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT’D) 


XI 6  INDIVIDUAL 

TECHNOLOGY 

STATE  OF  THE  TECHNOLOGY 

DOCUMENT 
SCANNING  and 
CONVERSION 

RELEVANCE: 

Current  AF  inven¬ 
tor}  of  TOs  is  held 
in  paper  form,  but 
AFTOMS  is  most 
effective  in  handl¬ 
ing  digital  TOs. 
Management  of 

TOs  is  a  recurring 
operational  cost 
which  is  reduced 
when  TOs  are  in 
digital  form.  TOs 
are  used  for  many 
years  (e.g.,  20  -30 
years)  and  are 
changed  and  reis¬ 
sued  many  times 
during  their  life 
cycle,  a  dynamic 
process  which  is 
better  controlled 
and  facilitated 
through  automa¬ 
tion.  Conversion  is 
a  one  time  non-re¬ 
curring  cost. 

Given  the  POC 
work,  this  section 
assesses  key  tech¬ 
nological,  opera¬ 
tional,  and  eco¬ 
nomical  issues  as¬ 
sociated  with  con¬ 
version  of  a  large 

TO  inventory. 

FY89: 

Conversion  of  paper  databases  into  digital  form  is  one  of  the  more  chal¬ 
lenging  endeavors  in  the  computing  world  today.  An  economically  viable 
approach  to  apply  automated  technology  to  massive  amounts  of  often  com¬ 
plex  technical  information  in  paper  form  (e.g.,  AF  TOs)  is  the  key  factor. 
Over  the  past  few  years,  there  have  been  significant  developments  in  con¬ 
version  and  conversion-related  products.  An  earlier  widespread  view,  seen 
in  existing  hardware  solutions,  that  the  bulk  of  the  conversion  effort  and 
complexity  exists  in  the  physical  scanning  part  of  the  total  conversion  pro¬ 
cess  is  now  being  modified  to  recognize  that  the  scanning  portion  of  the 
process  is  only  a  small  part.  The  m^jor  challenges  are  in  recognition  soft¬ 
ware  development  and  this  is  where  most  of  the  complexity  lies  and  new 
activity  is  taking  place.  This  flurry  of  activity  can  best  be  described  as  devel¬ 
opment  of  ’’niche”  products  which  focus  on  specific  areas  of  the  process. 

Much  of  this  activity  is  being  done  by  innovative  small  software  companies 
and  start-ups.  These  niche  products  can  be  integrated  with  other  products 
and  manual  labor  to  build  a  total  conversion  solution.  In  fact,  many  compet¬ 
ing  partially  integrated  solutions  use  the  same  basic  component  products. 
Fully  integrated  solutions  are  not  currently  available  in  the  marketplace. 
Thus,  in  FY89,  the  burden  of  integrating  niche  products  into  a  total  solu¬ 
tion  lies  with  the  user.  Current  and  future  technical  capabilities  of  scan¬ 
ning  devices  and  recognition  techniques  were  reviewed  in  the  context  of  a 
process  to  understand  the  conversion  issues.  In  FY89: 

■  Document  scanning  is  furthest  along  in  product  maturity,  many 
scanners  exist  at  all  price  ranges  (as  low  as  $2000)  that  can  scan 
paper  documents  and  produce  page  image  files; 

■  Tfext  character  (OCR)  and  graphics  recognition  products  usually 
work  as  embedded  post -processors  to  scanners;  while  others 
are  standalone  products  that  accept  scanned  raster  or  dot  image 
files  as  input; 

■  Auto  tagging  of  scanned  regions  as  laid-out  document  elements  is 
not  nearly  as  far  along  as  OCR  recognition  in  terms  of  product 
availability  and  maturity;  and 

■  SGML  support  produced  very  little  product  development  activity 
until  recently,  the  emergence  of  the  CALS  Initiative  has  fostered 
some  development  of  products  that  just  recently  became  available; 
in  some  cases,  this  capability  can  be  embedded  in  auto  tagging 
products  where  products  can  exist  either  as  enhanced  versions  of 
auto  tagging  modules,  which  tag  directly  in  SGML  or  convert 
existine  taes  to  SGML  taes,  or  as  standalone  products. 

FY91-FY93: 

During  the  next  few  years,  a  tremendous  amount  of  effort  will  occur  in  the 
electronic  publishing  industry  to  produce  useful  conversion  products.  This 
effort  will  concentrate  on  making  significant  strides  in  3  areas: 

■  Developing  integrated  solutions  for  the  total  conversion  process; 

■  Improving  autochecking,  error  delection/correction  capabilities;and 

■  Developing  robust,  production-oriented  products  requiring  mini¬ 
mal  user  labor  (thereby  reducing  costs  below  $1  per  page,  which 
should  be  economically  acceptable  for  the  Air  Force  conversion). 
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TABLE  3-1.  SUMMARY  OF  TECHNOLOGY  FINDINGS  FOR  AFTOMS  (CONT'D) 


INDIVIDUAL 
TECHNOLOGY 
T16  (CONT’D) 


DOCUMENT 
SCANNING  and 
CONVERSION 


FY91-FY93  RISK 


LEGEND 


RISK  ASSESSMENT 
SYMBOLS: 

■  HIGH 


MEDIUM 


ASSESSMENT 


The  electronic  publishine  industry 
sector  has  now  been  in  .  jtence  for 
over  five  years  and  most  of  the  basic 
capabilities  have  been  developed  by 
many  vendors.  Most  publishers  and 
distributors  of  technical  documenta¬ 
tion  have  some  amount  of  inventory 
that  existed  before  they  cut  over  to 
in-house  electronic  publishing.  Over 
the  next  few  years,  conversion  of 
data  from  paper  to  digital  form 
most  likely  will  be  a  high  priority 
issue  in  the  electronic  publishing  in¬ 
dustry.  The  availability  of  largely- 
automated  conversion  products, 
both  standalone  and  integrated  into 
publishing  systems,  is  needed  for  a 
total  solution  to  the  publishing 
problem.  A  review  of  the  different 
conversion  strategies  and  the  asso¬ 
ciated  technologies  shows  that  a 
considerable  amount  of  risk  lies  in 
the  following  areas: 

9  A  tremendous  amount  of  trained 
I  manual  labor  is  required  in  cur- 
rently  available  conversion  pro¬ 
cesses.  This  labor  is  required  for 

■  Post-scanning  checking  and 
cleanup;  even  though  scanning 
success  ratios  exceed  98%,  the 
entire  document  must  be 
checked  to  identify  and  correct 
the  small  percentage  of  scat¬ 
tered  residual  errors; 

"  Integration  of  the  entire  pro¬ 
cess  is  still  a  problem;  since 
most  capabilities  are  "niche” 
solutions,  a  considerable 
amount  of  work  is  needed  to 
support  a  productive  process; 
and 

*  Retrofitting  old  documents  to 
new  standardized  and  com¬ 
pliant  formats  (  M1L-STD- 
1840  DTDs  and  OSs)  can  be 
problematic  and  thus  requires 
detailed  human  judgment. 


ABATEMENT 


Most  of  the  identified  conversion 
risks  focus  on  the  fact  that  industry 
has  had  very  little  practical  experi¬ 
ence  in  applying  conversion  technol¬ 
ogy  to  large-scale,  production-based 
conversion  efTorts  for  complex  Wh- 
nical  documents  such  as  TOs.  While 
many  of  the  technology  components 
are  becoming  available,  a  better  un¬ 
derstanding  of  the  operational  is¬ 
sues  of  using  these  conversion  prod¬ 
ucts  is  needed.  Such  experience 
would  also  supply  a  lot  of  realistic 
financial  details  needed  to  plan  and 
operate  a  successful  conversion  op¬ 
eration.  The  following  activities  are 
recommended  as  abatement  strate¬ 
gies  to  mitigate  the  identified  collec¬ 
tive  conversion  risks: 


□  Perform  conversion  planning 
based  on  real  Air  Force  experi¬ 
ence  by. 

■  Starting  to  use  the  tech¬ 
nology  as  soon  as  possi- 


Applying  the  technology- 
in  a  limited  operational 
effort  to  a  representative 
suite  of  TOs; 

Identifying  and  quantify¬ 
ing  all  costs  (operational 
and  hidden)  that  are  part 
of  the  conversion  pro¬ 
cess;  and 

Doing  as  much  testing, 
evaluation,  and  tuning  as 
possible  before  entering 
into  full-scale  production 
conversion  for  remaining 
weapon  systems. 
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SECTION  4:  SUMMARY  OF  RISK  ASSESSMENT 

AND  CONCLUSIONS 


4.1  INTEGRATED  RISK  ASSESSMENT  OF  AFTOMS 

The  focus  of  the  AFTOMS  POC  work  is  risk  assessment  and  risk  abatement.  Fundamentally, 
this  activity  is  performed  by  developing  a  thorough  project  understanding  using  a  balanced 
combination  of  techniques.  First,  through  using  hands-off  methods  that  require  detailed 
analysis:  exploring  the  To-Be  concept  analytically  and  systematically  to  probe  for  logical 
needs,  problems,  and  consequences.  Secondly,  through  hands-on  Demo  System  or  technolo¬ 
gy  evaluation  work:  prototyping  to  test  and  verify  the  analysis,  evaluating  technologies  and 
products  relative  to  the  specific  needs  of  AFTOMS,  and  disclosing  subtle  integration  prob¬ 
lems  overlooked  in  the  hands-off  analysis. 

Prior  to  the  start  of  the  POC  effort,  the  prevailing  perception  within  the  AFTOMS  community 
was  that  state-of-the-art  and  emerging  technologies  posed  the  greatest  risks  to  project  suc¬ 
cess.  However,  by  the  end  of  the  first  three  months  of  POC  work,  which  focused  on  refining  the 
To-Be  concept  and  evaluating  numerous  candidate  technology  products,  it  became  apparent 
that  there  were  more  significant  risks  present  in  various  dimensions  of  integration.  In  retro¬ 
spect,  this  is  not  surprising  since  a  complex  system's  behavior  and  quality  is  often  influenced 
more  by  the  quality  of  the  interfaces  and  interactions  between  its  components  than  by  the 
individual  performances  of  the  components.  Therefore,  the  scope  of  the  POC  was  amended 
by  TSC  with  SPO  concurrence,  to  incorporate  eight  additional  risk  evaluations  into  the  list  of 
sixteen  technology  risk  evaluations,  thereby  performing  a  more  complete  and  thorough  POC. 

TSC’s  FY89-FY90  POC  approach  focuses  on  AFTOMS,  its  operating  environment,  and  im¬ 
portant  risk  issues  within  two  time  frames:  FY89  for  an  assessment  of  the  current  status  of 
technologies,  products,  integration  problems,  and  other  risks;  and  FY91-93  to  project  the 
future  status  of  the  same  items  for  the  period  when  the  full-scale  AFTOMS  is  designed  and 
built.  The  POC  approach  is  a  disciplined  one  that  evaluates  important  issues  of  consequence 
to  AFTOMS,  rather  than  getting  sidetracked  onto  trivial  or  interesting  ones.  It  is  a  multidi¬ 
mensional  approach  that  incorporates  users,  work  procedures,  operational  constraints,  tech¬ 
nologies,  and  interfacing  issues.  It  is  also  integrated,  making  optimum  use  of  the  comparative 
advantages  of  ”arious  techniques  to  explore  all  aspects  of  an  issue,  then  balancing  and  com¬ 
bining  those  investigations  and  results  for  overall  coverage  and  synergy.  Finally,  it  is  an  ac¬ 
tion-oriented,  mature  approach  designed  to  make  its  findings  clear  and  easy  to  use  during  the 
rest  of  the  project  life  cycle. 

The  following  summary  assessment  covers  the  FY91-FY93  time  period.  The  objective  is  to 
focus  the  reader’s  attention  on  the  greatest  Post-POC  risk  contributors  using  a  Risk  Atten¬ 
tion  Index  (RAI). 
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4.1.1  Integration  Dimensions 


Eight  dimensions  of  integration  were  identified  in  Section  2.2.1  as  relevant  to  AFTOMS, 
either  in  the  short  or  long  term.  The  Post-POC  risk  contribution  of  each  dimension  can  be 
assessed  in  terms  of  its  five  component  risks,  defined  in  Section  2.2.2:  functionality,  perform¬ 
ance,  seamlessness,  flexibility,  and  doability.  Using  these  five  risk  category’  definitions. 
TABLE  4-1  summarizes  the  risk  assessment  against  each  risk  category  for  each  of  the  eight 
dimensions  of  integration.  This  assessment  is  based  on  applying  judgmental  weighting  factors 
(1,  2.  and  3  for  low,  medium,  and  high,  respectively)  to  the  detailed  findings  described  in  Ap¬ 
pendix  B. 

TABLE  4-1.  RISK  INDEX  FOR  INTEGRATION  DIMENSIONS 


RISK  CATEGORIES 

INTEGRATION  DIMENSION 

Func¬ 

tionality 

Perfor-  Seam-  Flexi- 
mance  iessness  bllity 

Doa¬ 

bility 

TOTAL 

11 

Management  of  distrib¬ 
uted  user  functionality 

1 

1 

2 

1 

1 

6 

12 

Handling  and  conversion 
of  heterogeneous  TO  data 

2 

3 

2 

1 

1 

9 

13 

Support  of  heterogeneous 
system  users 

1 

1 

3 

1 

1 

7 

14 

Use  of  electronic 
communication 

2 

1 

2 

3 

2 

10 

15 

Interface  to  other  Air 

Force  functions/systems 

3 

2 

3 

2 

2 

12 

16 

System  buildability 

2 

2 

3 

1 

1 

9 

17 

Reliance  on 

conformance  to  standards 

3 

1 

2 

2 

3 

11 

18 

Operational  utility 

3 

3 

2 

2 

2 

12 

The  TOTAL  column  in  TABLE  4-1  adds  the  component  risk  values  for  each  dimension  of 
integration:  in  effect,  weighting  each  component  equally  against  the  others.  This  produces 
the  Risk  Index,  an  estimate  for  the  residual  risk  present  in  that  dimension.  The  importance  of 


that  dimension  to  AFTOMS  is  again  judgmentally  weighted  on  a  scale  of  l-to-5,  low-to-high 
in  increasing  importance,  respectively,  shown  under  the  Contribution  column  in  TABLE  4-2. 
The  Risk  Attention  Index  for  each  dimension  of  integration  is  therefore  the  product  of  its 
Risk  Index  and  Contribution  value  (see  TABLE  4-2).  Thus,  if  either  or  both  the  Risk  Index 
and  the  Contribution  is  high,  the  resulting  Risk  Attention  Index  (RAI)  is  also  high,  signalling 
that  more  attention  should  be  paid  to  that  dimension  of  integration  instead  of  another  one 
whose  computed  RAI  is  much  lower.  The  maximum  RAI  is  15  x  5  or  75. 

This  model  shows  that  the  top  four  RAIs  belong  to:  Operational  utility  (60),  System  buildabil- 
ity  (45),  Interface  to  other  Air  Force  functions/  systems  (36),  and  Handling  and  conversion  of 
heterogeneous  technical  order  data  (36).  Those  dimensions  requiring  the  least  attention  are: 
Use  of  electronic  communication  (20)  and  Support  of  heterogeneous  system  users  (21). 

Conclusions  and  recommendations  related  to  these  attention-requiring  dimensions  of  inte¬ 
gration  are  presented  in  Section  4.2. 

4.1.2  Individual  Technologies 

Sixteen  individual  technologies  were  identified  in  Section  3.2.1  as  relevant  to  AFTOMS,  ei¬ 
ther  in  the  short  or  the  long  term.  The  Post-POC  risk  contribution  of  each  of  these  technolo¬ 
gies  can  be  assessed  in  terms  of  its  five  component  risks,  defined  in  Section  3.2.2:  functional¬ 
ity.  performance,  compatibility,  standards,  and  viability.  Using  these  five  risk  category 
definitions.  TABLE  4-3  summarizes  a  risk  assessment  against  each  category  for  each  of  the 
sixteen  technologies. 

The  TOTAL  column  in  TABLE  4-3  adds  the  component  risk  values  for  each  individual  tech¬ 
nology:  in  effect,  weighting  each  component  equally  against  the  others.  This  produces  the 
Risk  Index,  an  estimate  for  the  residual  risk  present  in  that  technology.  The  importance  of 
that  technology  to  AFTOMS  is  again  judgmentally  weighted  (on  a  scale  of  l-to-5,  low-to- 
high  in  increasing  importance,  respectively),  shown  under  the  Contribution  column  in 
TARLF  4-4.  The  RAI  for  each  technology  is  therefore  the  product  of  its  Risk  Index  and  Con¬ 
tribution  value.  Thus,  if  either  or  both  the  Risk  Index  and  the  Contribution  is  high,  the  result¬ 
ing  RAJ  is  also  high,  signalling  that  more  attention  should  be  paid  to  that  technology  than 
another  one  whose  computed  RAI  is  much  lower.  The  maximum  RAI  is  15  x  5  or  75. 

This  model  shows  that  the  top  six  RAIs  belong  to:  Document  Scanning  and  Conversion  (50), 
Optical  Disk  (36),  Government  Data  Interchange  Standards  (36),  User  Interface  Manage¬ 
ment  Systems  (35),  Technical  Publishing:  Document  Management  Systems  (32),  and  Object- 
Oriented  Data  Management  (26).  Those  technologies  requiring  the  least  attention  are:  De¬ 
mand  Printing  (12),  Workstation  Platforms  (15),  and  Communication:  LAN  (Id)  and  WAN 
(18). 

Conclusions  and  recommendations  related  to  these  attention-requiring  technologies  are 
presented  in  Section  4.2. 
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TABLE  4-2.  RISK  ATTENTION  INDEX  FOR  INTEGRATION  DIMENSIONS 


RISK  INDEX  * 

CONTRIBUTION  = 

RISK  ATTENTION  INDEX 

(Rl) 

(C) 

(RAI) 

INDEX 

RANKING 


RISK  ATTENTION  INDEX  (Top  4) 

1.  (18)  Operational  utility 

60 

2.  (16)  System  buildability 

45 

3.  (15)  Interface  to  other  AF  functions/ 
systems 

36 

4.  (12)  Handling  and  conversion  of 
heterogeneous  TO  data 

36 

TABLE  4-3.  RISK  INDEX  FOR  INDIVIDUAL  TECHNOLOGIES 


RISK  CATEGORIES 

TECHNOLOGY 

Func¬ 

tionality 

Perfor-  Seam-  Flexl- 
mance  lessness  bllity 

X‘  T0TAL 

T1 

Object-Oriented  Data 
Management  (OODM) 

T2 

Technical  Publishing:  Doc’t. 
Management  Systems  (DMS) 

T3 

Distributed  Relational 
Database  Mgt.  Sys. (RDBMS) 

T4 

User  Interface  Ma^aqe- 
ment  Systems  (UIMS) 

T5 

On-Line  Delivery  Systems 
(ODS) 

T6 

Local  Area  Communications 

T7 

Wide  Area  Communications 

T8 

Optical  Disk 

T9 

Demand  Printing 

T10 

Workstation  Platforms 

Til 

Document  B  + 

Enhancements 

T12 

Software  Design/ 
Implementation  Languages 

T13 

Government  Data 

Interchange  Standards 

T14 

De  facto  and  De  jure 
Computer  Industry  Standards 

T15 

training  Technologies  and 
AFTOMS  Assimilation 

T16 

Document  Scanning  and 
Conversion 

L  =  1 ,  M  =  2,  H  «  3 
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*  T1-T16  refer  to  appendices  in  the  draft  SPO  Supplement 
Report  (see  Section  1) 
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TABLE  4-4.  RISK  ATTENTION  INDEX  FOR  INDIVIDUAL  TECHNOLOGIES 


RISK  INDEX  * 

CONTRIBUTION  = 

RISK  ATTENTION  INDEX 

(Rl) 

(C) 

(RAI) 

INDEX 

RANKING 


RISK  ATTENTION  INDEX  (Top  6) 

1 .  (T16)  Document  Scanning  and  Conversion 

50 

2.  (T8)  Optical  Disk 

36 

3.  (T13)  Government  Data  Interchange  Standards 

36 

4.  (T4)  user  Interface  Management  Systems  (UIMS)  35 

5.  (T12)  Document  Management  Systems  (DMS) 

32 

6.  (T1 )  Object-Oriented  Data  Management  (OODM) 

26 
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4.2  CONCLUSIONS  AND  RECOMMENDATIONS 


Since  the  scope  of  the  POC  did  not  include  evaluation  of  Air  Force  organizational  issues,  the 
risks  associated  with  integrating  AFTOMS  into  the  Air  Force  culture  were  not  evaluated. 
However,  technologies  for  developing  a  high-quality,  user-friendly,  and  easy-to-learn  sys¬ 
tem  were  investigated,  thereby  indirectly  reducing  existing  organizational  risks  somewhat. 
The  following  findings  from  the  FY89-FY90  AFTOMS  POC  work  that  apply  to  the  AF- 
1 OMS  FSED  (FY91-FY93)are  extracted  from  the  detailed  evaluations  in  Section  2  and  Sec¬ 
tion  3.  They  are  organized  into  Major  Conclusions  and  Other  Conclusions  (of  a  less  critical 
natuie). 

MAJOR  C  OSCLVSIOSS 

•  No  single  COTS  product  or  turnkey  integrated  system  will  be  available  to 
satisfy  AFTOMS  requirements.  Given  the  uniqueness  of  the  requirements 
and  the  needed  technology  mix,  specific  capabilities  of  commercial  prod¬ 
ucts  used  selectively,  and  the  customized  software  written  to  unify  pur¬ 
chased  COTS  technology  products  into  one  seamless  AFTOMS  system,  the 
integration  risk  could  actually  exceed  the  total  technological  risk  associated 
with  particular  products:  however,  this  integration  risk  is  still  significantly 
smaller  than  that  which  would  result  if  AFTOMS  did  not  rely  on  commer¬ 
cial  technology  products,  but  attempted  a  totally  customized  solution  ap¬ 
proach 

•  The  AFTOMS  To-Be  concept  is  operationally  sound  and  can  be  built  by 
integrating  available  or  emerging  technology  products.  There  are  residual 
risks  associated  with  scanning  conversion,  defining  a  standardized  CTO- 
DO-to-WA  delivery  interface  to  support  heterogeneous  WA  delivery  sys¬ 
tems,  and  localized  technical  and  scheduling  problems.  However,  these  lo¬ 
calized  problems  should  be  manageable. 

•  The  AFTOMS  To-Be  concept  is  sufficiently  robast  to  manage  a  mixed  pa¬ 
per  and  digital  TO  inventory,  consisting  of  all  types  of  paper  and  digital 
TOs. 

•  MIL-STD  1840  must  be  completed  soon  since  timely  development  of  an 
adequate  set  of  consistent  DTDs  and  OSs  (to  cover  the  range  of  new  and 
existing  TOs)  is  critical  to  AFTOMS  success  for: 

o  Scanning  conversion  of  existing  inventory  of  paper  T Os  (which  because 
of  inconsistent  standards  historically  have  varying  formats  and  styles): 
o  Supporting  MIL-STD  1840  compliant  delivery  of  new  digital  TOs :  and 
o  Type  B  +  tagging  for  value-added  delivery  of  TOs  to  Work  Areas. 

•  Scanning  conversion  of  existing  weapon  system  TO  suites  is  important  to 
load  the  digital  database  for  AFTOMS.  Otherwise,  the  automation  benefits 
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will  fall  short  of  the  projections.  An  early  start  with  a  pilot  operation  is  rec¬ 
ommended  to  develop  a  good  basis  for  planning  and  executing  later  conver¬ 
sions  for  each  new  TOMA  before  it  becomes  operational. 

•  Type  EH-  TOs  provide  a  major  enhancement  to  the  original  AFTOMS  To- 
Be  concept.  Additional  SGML  tagging  of  newly  authored  or  converted  dig¬ 
ital  TO  contents  at  the  TOMA/TOC  level  can: 

o  Mark  text  content  by  security  level,  technician  skill  level,  aircraft  tail 
number,  etc.; 

o  Interconnect  related  text  references  with  referenced  graphics. 

tables,  or  external  TOs;  and 
o  Establish  other  suitable  relationships. 

Such  tagging  provides  more  usable  TOs  at  Work  Areas  by  displaying  only 
the  information  needed  for  the  maintenance  task  (free  of  extraneous  de¬ 
tails)  and  facilitating  rapid,  accurate  retrieval  of  referenced  or  related  tech¬ 
nical  data.  Type  B-i-  provides  the  Type  C  benefit  of  tailored  views  at  Work 
Areas  without  the  need  for  additional  sophisticated  AFTOMS  software. 
From  a  Type  B  baseline,  B-t-  tagging  can  be  implemented  gradually  and 
incrementally.  With  Type  B  +  ,  for  example,  additional  tags  can  be  intro¬ 
duced  to  supply  new  capabilities,  or  old  ones  removed  to  reduce  tagging 
cost  or  risk  if  there  are  DTD/OS  deficiencies. 

•  The  existing  inventory  of  paper  TOs  is  extensive;  up  to  50%  can  be  con¬ 
verted  economically  to  Type  B  digital  form.  Weapon  systems  will  acquire 
new  TOs  in  digital  form,  primarily  B  or  B-I- .  Some  new  weapon  systems 
(e.g.  ATF)  plan  to  acquire  Type  C  TOs.  as  well  as  rely  on  a  substantial  num¬ 
ber  of  existing,  non-Type  C  commodity  TOs.  Conversion  of  such  commod¬ 
ity  TOs  to  Type  C  format  would  be  costly  because  it  would  require  a  yet 
undefined,  re-authoring  approach.  Prior  to  FY2000,  Type  C  TOs  will  com¬ 
prise  a  very  small  percentage  of  the  Air  Force  TO  inventory.  With  this  in 
mind,  there  are  several  findings  and  recommendations: 

°  AFTOMS  must  and  will  support  Type  C  TOs  when  future  weapon 
systems  require  TO  management  support,  but  initially,  AFTOMS 
should  focus  on  conversion  and  Type  B  support;  and 
o  A  preliminary  high-level  POC  assessment  of  providing  Type  C  sup¬ 
port  shows  that  AFTOMS  needs  to  develop  additional  sophisticated 
software  systems.  These  systems  require  trained  personnel  to  con¬ 
currently  support  two  (Types  B  and  C)  significantly  different  ap¬ 
proaches  to:  TO  authoring:  change  implementation;  verification  of 
the  database  indexing  infrastructure  and  all  allowable  Work  Area 
views  into  the  TO  database;  and  delivery  of  these  views  from  CTO- 
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DOs  to  Work  Areas.  Work  Area  user  access  into  the  Type  C  neutral 
TO  database  would  have  to  be  restricted  to  formally  verified 
predefined  views. 

•  Technology  will  not  support  an  AFTOMS  solution  that  can  handle  both 
classified  and  unclassified  TOs  in  a  fully  integrated,  secure,  and  trustworthy 
fashion;  therefore,  a  physically  secured,  separate  (but  functionally  identi¬ 
cal)  mini-AFTOMS  is  recommended  for  handling  classified  TOs. 

•  Key  undecided  operational  requirements  for  system  usage  (e.g.,  change 
management  at  Tier  2,  TO  information  traversal  at  Tier  4)  affect  the  design 
of  AFTOMS  in  broad  and  fundamental  ways  and  need  early  resolution. 

•  A  standard  AFTOMS  interface  between  CTODO  and  Work  Area  delivery 
systems  should  be  defined  so  that  IMIS,  ITDS,  and  other  future  MAJCOM 
systems  can  easily  interface  to  AFTOMS. 

OTHER  CONCLUSIONS 

•  Graphical  user  interfaces  developed  in  the  Demo  System  appear  to  satisfy 
in  “look  and  feel"  the  needs  of  all  major  user  types  across  the  four  tiers;  and 
are  a  major  contributor  to  the  seamless  integration  of  AFTOMS;  these 
benefits  more  than  offset  their  additional  development  complexity  and 
cost. 

•  Installation  of  AFTOMS  must  be  coordinated  with  various  Offices  of  Pri¬ 
mary'  Responsibility  (OPRs).  For  example,  AFCC  is  the  OPR  for  DDN  sup¬ 
port;  on  average,  it  takes  at  least  24  months  from  identification  of  a  require¬ 
ment  for  AFCC  to  install  a  DDN  communications  node. 

•  AFTOMS  buildability  risk  can  be  lowered  significantly  with  a  quality  set  of 
technical  and  operational  requirements  in  the  RFP  that  suitably  constrain 
any  contractor’s  solution  flexibility  and  provide  an  unambiguous  basis  for 
determining  if  a  proposed  and/or  implemented  solution  meets  AFTOMS. 
MAJCOM,  and  CALS  long-term  needs. 

•  Good  operational  utility  can  be  built  into  AFTOMS  to  support  its  post-ins¬ 
tallation  use  and  long-term  upgradability,  maintainability,  and  interoper¬ 
ability. 

•  Several  key  emerging  technologies  are  evolving  rapidly  and  should  be  mon¬ 
itored  closely:  DMS,  Distributed  RDBMS,  ODS,  and  UIMS. 

•  TO  distribution  from  TOM  A  to  CTODO  depends  on  bulk  optical  disks;  the 
lack  of  standards  increases  the  long-term  economic  risk  of  both  optical 
reader  assets  obsolescence  and  spare  parts  availability  when  the  technology' 
changes.  However,  any  necessary  data  conversions  necessitated  by  new 
standards  could  be  automated  easily. 
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•  Several  incompatibilities  exist  between  standards  that  may  not  be  resolved 
and  will  require  workarounds  (e.g.,  optical  disk  media  is  not  yet  accepted  by 
the  government  as  trustworthy  for  archival  storage  of  permanent  records, 

C+  +  is  not  yet  on  the  DoD  list  of  approved  higher-order  languages,  and 
ADA  [Programming  Language,  MIL-STD 1815]  has  not  been  ported  to  an 
X-Windows  environment,  etc.). 

•  A  few  technologies  were  found  to  be  inappropriate  for  use  on  AFTOMS 
before  FY2000,  either  because  they  were  too  risky  operationally,  immature 
for  interfacing  with  other  needed  technologies,  or  not  the  best  direct  ap¬ 
proach  to  providing  the  needed  capabilities  accurately  and  predictably 
(e.g.,  OODM  and  Artificial  Intelligence  (AI));  however,  AJ  may  still  be  use¬ 
ful  in  providing  localized  capabilities  (e.g.,  TO  numbering  based  on  content 
characteristics). 

Other  less  significant  conclusions  and  recommendations  are  contained  in  Sections  2  and  3, 
with  supporting  detail  found  in  the  referenced  Appendix  B  sections. 

4.2.1  Recommended  Followup  for  Risk  Abatement 

T  he  value  of  conducting  a  POC-type  risk  abatement  activity  to  develop  a  thorough  project 
understanding  before  trying  to  define  and  build  the  real  AFTOMS  is  practical  and  significant. 
It  anticipates  and  resolves  opportunities  and  problems  that  could  appear  later,  thereby  reduc¬ 
ing  the  total  burden  during  full-scale  development;  and  it  provides  a  coherent,  integrated, 
and  AFTOMS-specific  framework  for  quicker  evaluation  and  resolution  of  future  problems 
and  opportunities. 

The  risk  abatement  benefits  of  this  framework  are  numerous,  provided  they  are  used  as  lever¬ 
age  over  the  remaining  phases  of  the  project.  The  framework  reduces  project  risk  by  reduc¬ 
ing: 

•  Surprises  and  unintended  consequences  downstream; 

•  Changes  and  iterations  during  development; 

•  Schedule  slippages; 

•  Compromises  in  delivered  functionality,  performance,  and  system  quality; 

•  Follow-on  Engineering  Change  Proposals  (ECPs)  to  fund  after  project 
completion;  and 

•  Providing  a  means  to  prototype  high-risk  options  in  a  limited  environment 
without  jeopardizing  the  full-scale  effort  with  avoidable  problems. 

This  framework  can  also  be  used  to  train  system  developers,  IV  &  V  contractor  personnel, 
and  others,  to  understand  the  AFTOMS  requirements  and  technologies  more  quickly,  there¬ 
by  reducing  their  learning  curves  and  providing  a  partial  substitute  for  any  lack  of  AFTOMS- 
relevant  experience;  this  will  focus  development  activities  and  increase  productivity. 
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The  Demo  System  focused  on  understanding  and  implementing  key  aspects  of  the  To-Be  con¬ 
cept  functionality  using  technologies  and  products  that  are  suitable  for  AFTOMS.  In  the  pro¬ 
cess,  much  invaluable  hands-on  experience  was  gained  in  working  with  current  and  emerging 
scate-of-the-art  technologies,  integrating  technology  products  with  critical  AFTOMS  func¬ 
tionality,  finding  and  evaluating  technological  and  operational  problem  areas,  and  develop¬ 
ing  a  visible  and  dynamic  basis  for  refining  AFTOMS  requirements.  This  valuable  knowledge 
and  experience  base  can  be  built  upon  to  provide  additional  risk  abatement  value  to  AF¬ 
TOMS.  The  packaged  Demo  System,  installed  at  the  AFTOMS  SPO,  can  be  enhanced  fur¬ 
ther  and  used  as  follows: 

•  Provide  a  model  for  refining  RFP  requirements,  user  interfaces,  and  source 
selection  criteria  to  reinforce  a  coordinated  and  tested  view  of  AFTOMS; 

•  Provide  a  system  capability'  which  can  be  enhanced  to  assess  and  develop 
critical  technical  issues  (e.g.,  TO  conversion  automation,  database  model 
selection,  distributed  data  loading,  system  performance.  Tier  4  interfaces 
for  selected  MAJCOM  TO  delivery  systems,  DTD/OS  and  other  CALS 
standards  testing,  organizational  infrastructure  issues,  etc.);  see  Summary 
Sections  2.2.3  and  3.2.3  for  a  more  details; 

•  Serve  as  a  low-cost  test  bed  before  and  during  AFTOMS  FSED  for  inde¬ 
pendently  evaluating  problems  and  alternative  solutions  without  disrupting 
the  main  AFTOMS  development  effort  (e.g.,  integration  of  Type  C  support 
into  AFTOMS,  or  using  the  Demo  System  to  get  a  dynamic  feel  for  how  the 
functionality  operates  and  interacts  before  partitioning  the  functionality 
across  organizational  elements  based  on  historical  patterns); 

•  Provide  a  dynamic  test  bed  for  developing  user  training  approaches  and 
materials;  and 

•  Demonstrate  AFTOMS  to  managers  and  users  from  USAF,  DoD,  and  in¬ 
dustry  to  support  the  CALS  Initiative. 
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AFTOMS  AUTOMATION  PLAN 


SECTIONAL 

Introduction 


Al.l  INTRODUCTION 

Under  AFSC  CALS  MIO  sponsorship  in  1987,  TSC  developed  a  7-10  year  automation  plan 
for  TOs,  published  in  the  Air  Force  Technical  Order  Management  System  (AFTO MS)  Automa¬ 
tion  Plan,  Final  Report,  dated  February  1988,  document  number  DOD-VA-856-88-3.  This 
appendix  presents  overviews  from  that  report  of  the: 

•  Modular  Planning  Process  (MPP)  (Section  A2)  used  to: 

o  Examine  the  As-Is  environment; 
o  Study  opportunities  for  TO  automation;  and 
o  Plan  the  direction. 

•  AFTOMS  Automation  Plan  (Section  A3)  in  terms  of  its: 

o  Scope: 

o  As-Is  Findings;  and 

o  Proposed  To-Be  TO  System  Concept. 

In  addition  to  providing  general  and  valuable  background  material,  the  To-Be  System  Con¬ 
cept  in  Section  A3. 4,  taken  from  the  AFTOMS  Automation  Plan,  provides  an  introductory 
description  of  important  TO  and  AFLC  infrastructure  concepts  required  to  understand  this 
AFTOMS  Technology  Issues  &  Alternatives  Rep  irt  and  the  POC  findings.  The  organization¬ 
al  terminology  previously  used  in  the  Automata  n  Plan  has  been  recently  updated  to  reflect 
current  thinking  within  the  AFTOMS  SPO. 
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SECTION  A2: 
AFTOMS  Modular  Planning 


A2.0  AFTOMS  MODULAR  PLANNING 


TSC  developed  and  implemented  the  MPP,  an  information  engineering  system  planning  ap¬ 
proach,  to  perform  the  activities  associated  with  the  CALS  initiatives.  The  principal  require¬ 
ments  of  the  MPP  were  to: 

•  Focus  on  technical  plans  that  would  not  become  outdated  before  imple¬ 
mentation; 

•  Incorporate  existing  transition  systems; 

•  Meet  the  information  distribution  requirements  of  the  user  community, 
and 

•  Interface  with  a  variety  of  organizations  responsible  for  weapon  systems  ac¬ 
quisition  and  logistics  support. 

The  MPP  has  three  distinct  phases  listed  below  with  the  timeframe  noted  in  which  they  were 
conducted  for  AFTOMS: 

•  As-Is:  an  examination  of  the  existing  environment  (March-June,  1987); 

•  To-Be:  a  study  of  opportunities  and  initial  formulation  of  a  system  concept 
for  automation  (May- August,  1987);  and 

•  Automation  Plan:  consensus  building  within  the  Air  Force  for  refining  the 
concept,  mobilizing  action  on  it,  and  developing  a  plan  for  future  direction 
(July  1987-January  1988). 

The  TO  planning  team  consisted  of  systems  engineers  and  technical  staff  with  strategic  plan¬ 
ning  and  organizational  skills.  Team  members  met  with  different  groups  within  the  Air  Force 
and  industry  to  discuss  the  existing  system  (its  characteristics,  dimensions,  problems,  etc.), 
technology  options,  and  viable  alternatives. 

An  overview  of  the  MPP  is  presented  in  TABLE  A2-1  to  give  the  reader  an  indication  of  the 
steps  needed  to  complete  this  process.  Using  the  framework  of  the  MPP,  TSC  developed  an 
automation  plan  for  TOs. 

The  AFTOMS  concept  that  evolved  from  this  process  was  a  result  of  melding  this  analysis 
with  ideas  received  from  the  Air  Force  and  industry,  which  formed  the  published  AFTOMS 
Automation  Plan  -  Final  Report,  dated  February  1988. 
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TABLE  A2-1.  MODULAR  PLANNING  PROCESS  -  OVERVIEW 


EXAMINE  THE  ENVIRONMENT 

STUDY  THE  OPPORTUNITIES 

PLAN  THE  DIRECTION 

Initiate  the  Process 

Perform  Initial  Assessment 

•  Create  Preliminary  Description 
of  Environment 

•  Identify  Organization 

Expectations 

■  Establish  Priorities 

Develop  Specific  Procedures 

•  Establish  Management  Plan 

■  Identify  Advisory  Group 

•  Prepare  Project  Plans 

Conduct  Structured  Analysis 

Describe  Current  Environment 

•  Create  Functional  Model 

•  Identify  Major  Data  Elements 

•  Describe  the  Organizational 
Infrastructure 

•  Identify  Major  Information 

Flow  Parameters 

Assess  Transitional  Projects 

•  Identify  Objectives 

•  Describe  Functions  and  Data 

•  Identify  Technologies 

•  Identify  Infrastructure  Affected 

Assess  Technotoav 
Identify  Existing  Technologies 

•  Review  Current  Environment 

•  Review  Ongoing  Projects 

•  Identify  Existing  Technologies 

Research  Future  Technology 
Opportunities 

•  Select  Technology  Areas 

•  Consult  with  Technology 

Experts 

•  Examine  Similar  Applications 

•  Review  Development  Trends 

Establish  Teci.nology 

Alternatives 

•  Quantify  Directions 

•  Specification  of 

Implementation  Issues 

■  Examine  Benefits  and  Costs 

Project  Future  Reauirements 

Forecast  Requirements 

•  Review  Applicable  Scenarios 

•  Conduct  Discussions  wfth 
MAJCOMs 

•  Forecast  Process  Changes 

■  Assess  Infrastructure 

Constraints 

Examine  Feasible  Alternatives 

•  Determine  Feasibility  Issues 

■  Review  Industry  Trends 

Define  Future  State 

Describe  Future  Environment 

•  Define  the  Impact  of 

Technology  on  Current  State 

•  Define  Projected 

Organizational  Responsibilities 

•  Define  Relevant  interface 
Requirements 

Create  Future  Functional  Model 

•  Develop  a  Description  of 

Future  State 

■  Identify  Projected  Major 
Information  Flow  Parameters 

Formulate  Alternatives 

Assess  Critical  Issues 

•  Examine  Objectives 

•  Identify  Technologies 

•  Review  Organizational  Issues 

Propose  Initial  Alternatives 

•  Select  Future  Requirements 

•  Identify  Technologies 

•  Structure  Proposals 

Review  and  Modify  Alternatives 

•  Review  Criteria 

■  Identify  Relationships  with 

Transitional  Projects 

•  Define  Policies  and 

Organizations  Involved 

Develop  Consensus 

Review  Progress  with  Advisory 

Group 

•  Identify  Discussion  Topics  and 
Priorities 

•  Evaluate  Current  Environment 

•  Establish  Objectives 

•  Provide  Access  to  Information 

Develop  Common  Understanding 

•  Review  Future  Requirements 

•  Evaluate  Recommended  Solutions 

•  Examine  Feasibility  Issues 

Expand  Advocacy  Network 

•  Identify  Implementation  Agencies 

•  Select  Appropriate  Forums 

•  Communicate  the  Plans 

Prepare  Implementation  Plan 
Define  Activity  Descriptions 

•  Establish  Implementation 

Guidelines 

'  Establish  Evaluation  Criteria 
'  Develop  Implementation 

Procedures 

Develop  Organization  Plan 

■  Confirm  Major  Milestones 

•  Establish  Transition  Plan 

•  Identify  Organizational 

Responsibilities 

Establish  Constituency 

■  Gain  Management  Acceptance 
of  Plan 

■  Obtain  a  Commitment  for 

Execution 

Create  Documentation 

■  Establish  Goals 

■  Define  Resource  Requirements 

•  Recommend  Technologies 

D"«ne  Organizational  Impacts 

•  Establish  Financial  Parameters 

A2-2 


SECTION  A3: 
AFTOMS  Automation  Plan 


A3.1  AFTOMS  AUTOMATION  PLAN 


The  CALS  MIO,  with  guidance  from  the  Air  Staff  and  MAJCOMs,  established  and  implem¬ 
ented  several  key  objectives  for  the  AFTOMS  Automation  Plan  which  included: 

•  Acquiring  an  operational  system  by  the  mid-1990s; 

•  Defining  a  modular  strategy  which  allowed  for  phased  introduction  of  auto¬ 
mation  and  associated  organizational  changes;  and 

•  Defining  an  approach  which  addresses  the  major  deficiencies  of  the  current 
system  while  accommodating  the  need  to  effect  a  smooth  transition  by: 

o  Incorporating  as  many  existing  assets  as  possible  (automation  pro¬ 
jects,  organizations,  facilities); 

o  Allowing  parallel  operations  to  proceed  until  the  implementation  is 
completed;  and 

o  Providing  for  conversion  of  the  existing  inventory  of  TOs  to  digital 
form  and  subsequent  management  of  these  TOs  in  an  automated 
fashion. 

Long  term  goals  were  also  considered.  These  included: 

•  Developing  a  flexible,  modular  system  concept  to  provide  a  strong  founda¬ 
tion  for  the  long  term  (25  years); 

•  Preparing  the  Air  Force  for  paperless  use  and  processing  of  digital  TOs  and 
related  management  information;  and 

•  Integrating  TO  data  with  other  types  of  technical  information,  both  from 
system  automation  and  organizational  perspectives. 

A3.2  SCOPE  OF  THE  PLAN 
The  AFTOMS  plan  addressed: 

•  Strategic  issues  such  as  the  broad  characteristics  of  the  final  system,  manag¬ 
ing  the  transition  process,  and  establishing  centralized  procedures  for  sev¬ 
eral  activities; 

•  Organizational  issues  such  as  establishing  an  organizational  infrastructure 
for  future  system  functions  with  responsibilities  of  each  organizational  lay¬ 
er;  and 

•  Technical  issues  such  as  types  of  automation  systems,  communication  links, 
and  level  of  automation. 

The  above  issues  are  interdependent,  and  the  plan  defined  priorities  within  strategic,  organ¬ 
izational,  and  technical  areas. 
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The  resulting  AFTOMS  Automation  Plan  is  a  synthesis  of  the  tasks  performed  and  includes: 

•  Analysis  of  existing  TOs  and  data  flows; 

•  Examination  of  applicable  technology  trends  and  standards; 

•  Analysis  of  organizational  and  strategic  issues; 

•  Description  of  the  future  TO  system;  and 

•  Key  organizational,  technical,  financial,  and  programmatic  recommenda¬ 
tions. 

A3.3  SUMMARY  OF  THE  AS-IS  TECHNICAL  ORDER  SYSTEM 

The  Air  Force  established  the  existing  TO  system  in  the  1940s.  This  system  provides  the  offi¬ 
cial  medium  for  disseminating  technical  information,  instructions,  and  safety  procedures  per¬ 
taining  to  Air  Force  systems  and  equipment.  According  to  Air  Force  Regulation  (AFR)  8-2, 
TOs  are  military  orders  issued  in  the  name  of  the  Chief  of  Staff,  L’SAF,  by  order  of  the  Secre¬ 
tary  of  the  Air  Force,  and  require  mandatory  compliance.  The  existing  TO  system  is  manually 
oriented.  See  FIGURE  A3-1  for  the  current  TO  functional  structure. 
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FIGURE  A3-1.  CURRENT  TECHNICAL  ORDER  FUNCTIONAL  STRUCTURE 
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Currently,  there  are  over  150,000  TOs  in  use.  The  TOs  are  managed  by  five  (5)  ALCs  and  an 
Aerospace  Guidance  and  Metrology  Center  (AGMC),  which  are  divided  by  specific  weapon 
system  or  commodity.  The  average  TO  ranges  from  100  to  150  pages  in  length,  is  60%  text, 
and  40%  graphics.  The  total  TO  database  exceeds  20  million  original  pages  of  master  copy 
(exclusive  of  working  and  distributed  copies).  Annual  production  of  change  pages  averages 
approximately  2.3  million  original  pages.  In  addition,  the  current  and  growing  backlog  of 
unfilled  change  requirements  is  estimated  to  exceed  2  million  pages. 

A3.3.1  Existing  Technical  Order  Generation  And  Distribution 

In  general,  AFSC  is  responsible  for  the  acquisition  and  preparation  of  TOs.  AFSC,  through 
the  SPO  for  each  major  system  acquisition,  establishes  a  Technical  Order  Management 
Agency  (TOMA)  to  oversee  the  development  and  acquisition  of  TOs.  The  TO  Center  (TOC) 
of  the  ALC,  which  has  been  designated  as  the  prime  support  base  for  the  weapon  system, 
provides  the  technical  support.  The  contractor-prepared  Technical  Manual  Plan  (TMP), 
which  is  compatible  with  the  Air  Force  Technical  Order  Development  Management  Plan 
(TODMP).  is  used  to  produce  a  draft  TO.  The  TOMA  conducts  an  in-process  review.  The 
final  version  of  the  TO  set  must  be  validated  by  the  contractor  and  verified  by  appropriate  Air 
Force  commands,  such  as.  Military'  Airlift  Command  (MAC),  Tactical  Air  Command  (TAC). 
and  Strategic  Air  Command  (SAC).  The  ALC  is  responsible  for  storing,  printing  and  distrib¬ 
uting  the  verified  TO. 

Four  major  USAF  commands  are  involved  in  the  creation,  use,  and  management  of  TOs. 
AFSC  acquires  major  systems,  monitors  product  development  contracts,  and  conducts  test 
and  evaluation  efforts  (including  TO  verification  and  validation)  with  the  assistance  of  using 
and  supporting  commands.  The  major  command  or  commands  (MAJCOM)  that  use  the 
weapon  system,  also  provide  functional  requirements,  technical  specifications,  and  partici¬ 
pate  in  test  and  evaluation  efforts.  Within  AFLC,  the  ALCs  provide  the  operational  logistic?) 
support,  including  TO  maintenance  and  distribution  required  for  effective  operation  and 
maintenance  of  the  weapon  system.  Air  Training  Command  (ATC)  provides  a  wide  range  of 
training  associated  with  the  operation  and  maintenance  of  systems  including  the  use  of  TOs. 
FIGURE  A3-2  illustrates  the  procedures  for  generating,  ordering,  and  distributing  TOs. 

Users  requiring  specific  TOs  send  an  Air  Force  Technical  Order  (AFTO)  Request,  Form  187, 
to  a  Technical  Order  Distribution  Office  (TODO).  The  TODO  orders  the  requested  TOs 
from  the  Oklahoma  City  ALC  (OC-ALC)  central  distribution  point.  The  OC-ALC  center 
sends  a  mailing  label  to  the  appropriate  ALC  which  is  responsible  for  the  specific  TO,  and 
mails  the  TO  to  the  TODO.  Revisions  and  supplements  follow  a  similar  procedure. 
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A3.3.2  Existing  System  Deficiencies 


A  report  of  the  Headquarters  (HQ)  Air  Force  Audit  Agency  (AFAA)  (Audit  #5036410,  Ac 
quisition  of  Technical  Orders  from  Contractors,  dated  24  June  1986)  cited  several  deficien 
cies  in  the  existing  system.  These  included: 


•  Contractors  frequently  failed  to  provide  installation-level  TOs  in  time  for 
Air  Force  verification; 

•  At  times,  500  days  are  needed  to  fully  implement  a  routine  change  to  a  TO; 


•  Desk-top  analysis  and  validation  of  TOs  is  frequently  performed  in  lieu  of 
actual  performance  of  tasks; 


•  From  1977  to  1986, 47%  of  Cause  Code  1  (Inadequate  Technical  Data)  mis¬ 
haps  listed  inaccurate  TOs  as  a  contributing  factor  with  resulting  equip¬ 
ment  losses  of  about  $86  million; 


•  The  upfront  cost  to  develop  and  publish  a  TO  is  estimated  to  exceed  $1,000 
per  page  on  recent  weapon  systems  (i.e.,  Bl-B,  F16-C/D,  and  KC-135R); 
subsequent  TO  maintenance  costs  for  storage,  distribution,  management, 
changes,  etc.,  increase  this  cost  per  page  estimate;  and 

•  The  Air  Force  does  not  separate  the  cost  of  TO  preparation  from  the  cost 
of  a  weapon  system,  resulting  in  difficult  cost  control. 
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Therefore,  the  present  paper-oriented  system  is  inefficient  in  meeting  the  growing  require¬ 
ments  of  the  Air  Force.  A  single  weapon  system,  such  as  the  Bl-B,  generates  approximately 
3,500  new  TOs,  adding  one  million  pages  to  the  current  TO  database.  This  additional  volume 
cannot  be  managed  by  the  present  system  in  a  timely  fashion.  These  specific  facts  were  the 
basis  of  motivating  the  formulation  of  a  strategic  plan  that  would  lead  to  a  more  efficient  and 
powerful  TO  system,  capable  of  meeting  the  present  needs  and  the  future  requirements  of  the 
Air  Force.  Key  characteristics  of  this  future  TO  system  are  integrated  and  described  in  the 
AFTOMS  To-Be  concept.  Section  A3.4. 

A3.4  THE  TO-BE  TECHNICAL  ORDER  SYSTEM  CONCEPT 

In  developing  a  To-Be  system  concept  to  manage  the  acquisition  and  distribution  of  digital 
TOs,  consideration  was  given  to  a  modular  framework  that  would  easily  map  to  the  existing 
Air  Force  infrastructure.  Modularity  allows  phased  implementation  at  a  pace  consistent  with 
Air  Force  requirements  and  appropriations.  An  analysis  of  the  To-Be  system  concept  is  de¬ 
scribed  in  the  following  sections: 

•  Types  of  Technical  Orders; 

•  Organizational  Structure; 

•  Information  Flows; 

•  Interconnectivity; 

•  Major  Functionality;  and 

•  Concept  Highlights  and  Benefits. 

A3.4.1  Types  Of  Technical  Orders 

From  a  functional  view.  Air  Force  TOs  are  currently  divided  into  the  following  application 
categories: 

•  Technical  manuals; 

•  Abbreviated  TOs; 

•  Time  compliant  TOs; 

•  Methods  and  procedures  TOs; 

•  Index  TOs. 

The  basic  characteristics  of  each  category  of  TO  vary  widely  with  sub-divisions  existing  within 
each  category. 

In  formulating  the  AFTOMS  Automation  Plan  which  focuses  on  management  as  well  as  use 
of  TOs,  it  was  necessary  to  classifiy  TO  types  based  on  delivery  format  (digital  versus  paper) 
rather  than  based  on  the  above  application  categories.  Presently,  all  Air  Force  TOs  are  cre- 
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ated,  inventoried  and  distributed  as  paper  documents.  Although  many  of  these  documents 
are  created  and  maintained  by  contractor  systems  in  digital  form,  they  are  delivered  to  the  Air 
Force  as  paper  copies  since  the  current  Air  Force  TO  system  is  incapable  of  accepting  digital 
delivery.  The  existing  Automated  Technical  Order  System  (ATOS),  implemented  at  the  five 
(5)  ALCs  and  AGMC,  supports  selective  conversion  of  paper  documents  to  digital  files,  text 
and  illustration  file  creation,  maintenance  and  storage,  anc  reproduction  mastering  capabili¬ 
ties,  for  the  production  of  TO  change  pages.  However,  the  ATOS  system  is  used  to  handle 
only  a  small  portion  of  the  overall  TO  maintenance  workload,  which  is  itself  only  a  compo¬ 
nent  of  the  overall  process. 

Once  digital  acceptance  capabilities  are  provided  by  the  Air  Force  (using  MIL-STD-1840 
supported  by  standardized  Data  Type  Definition  (DTD)  and  Output  Specifications  (OS)),  sys¬ 
tems  can  be  designed  to  display  and  manipulate  the  TO  data  in  a  variety  of  ways.  A  digital  TO 
can  be  a  computer  based  display  of  the  paper  document  where  individual  pages  are  called  up 
for  display  or  printing.  Other  value-added  possiblities  include  automated  interconnection 
of  related  technical  material  and  tailoring  its  content  presentation  to  the  specific  mainte¬ 
nance  task,  technician  experience  level,  aircraft  tail  number,  etc.  A  more  advanced  concept 
would  link  individual  TO  data  elements  under  the  control  of  a  database  manager  which 
allows  the  user  to  assemble  related  TO  information  on  the  screen  interactively  as  tasks 
require.  To  develop  a  system  concept  that  serves  all  kinds  of  TOs  (present  and  future)  and 
their  relevant  automation  issues,  it  was  necessary  to  create  broad  delivery  categories  into 
which  all  TOs  could  be  subdivided.  These  delivery  categories  are  as  follows: 

•  Type  A:  characterizes  all  TOs  in  the  Air  Force  inventory  that  currently  exist 
or  will  be  delivered  in  paper  form.  Digitization  of  these  TOs  for  computer 
applications  will  require  selective  scanning. 

•  Type  B:  characterizes  TOs  that  will  be  delivered  to  the  Air  Force  by  the  con¬ 
tractor  in  editable  digital  form,  and  then  to  the  end  user  in  read-only,  pa¬ 
ge-oriented  form.  A  user,  sitting  in  front  of  an  electronic  display,  will  be 
able  to  view  and/or  print  any  desired  page(s)  of  the  TO  and  to  scroll  sequen¬ 
tially  across  pages.  The  ability  to  directly  access  the  required  page  on  the 
electronic  display  will  reduce  both  the  need  for  and  the  volume  of  printed 
information.  Two  variants  of  Type  B  have  also  been  defined: 

o  Type  B(- ■):  Type  B  minus  is  a  Type  A  that  has  been  raster  scanned  and  is 
editable  only  at  the  dot  level,  not  as  text  or  vectorized  graphic  illustra¬ 
tions;  therefore,  changes  are  more  difficult  to  make  to  a  Type  B(-)  TO 
than  to  a  Type  B  TO,  even  though  both  appear  the  same  to  the  user; 

o  Type  B( + ):  Type  B  plus  is  also  editable,  but  incorporates  invisible  tags 
in  the  content  that  facilitate  TO  use  by  allowing  tailoring  of  displayed 
material  to  be  specific  to  the  task,  aircraft  tail  number,  technician  expe¬ 
rience  level,  and  links  up  related  material  within  or  across  TOs. 
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•  Type  C\  characterizes  TOs  that  will  offer  the  highest  level  of  technological 
innovation.  These  pageless  TOs  will  be  delivered  by  the  contractor  to  the 
Air  Force  in  neutral  digital  database  form.  The  resulting  database  is  char¬ 
acterized  as  neutral  since  technical  data  is  stored  in  a  form  that  is: 

o  Fragmented  to  facilitate  reusability  and  minimize  redundancy; 

o  Independent  (or  neutral)  of  any  application  software  that  subsequently 
uses  it;  and 

o  Independent  of  any  style  or  form  used  to  output  such  data  to  a  screen 
display  or  a  printout. 

Such  neutral  data  is  more  easily  reusable  in  future  integration  requirements 
that  can  develop  from  the  CALS  initiative.  The  maintenance  technician 
will  be  able  to  use  an  electronic  display  to  search  and  retrieve  required  in¬ 
formation  from  a  neutral  database.  User  access  will  be  provided  to  related 
windows  of  information,  regardless  of  data  location  in  the  TO  or  the  data¬ 
base.  In  reality.  Type  C  TOs  have  no  page  orientation  and  are  significantly 
different  from  Type  A  and  Type  B  TOs.  There  is  one  variant  of  the  Type 
C: 

o  Type  C(-):  Type  C  minus  restricts  user  access  to  Air  Force  verified  fixed 
views  only,  so  that  arbitrary  combinations  of  user-defined  database  ele¬ 
ments  will  not  be  retrieved. 

A3.4.2  Organizational  Structure 

To  meet  the  objectives  of  more  accurate,  complete,  timely,  and  cost-effective  TOs,  it  is  neces¬ 
sary  to  establish  clearly  defined  responsibilities  and  logical  information  flows. 

The  AFTOMS  organizational  structure  is  designed  to  serve  the  natural  functional  entities 
that  must  reside  in  any  documentation  production  and  distribution  system.  These  functional 
groupings  include  general  administration,  acquisition  and  production,  ordering  and  distribu¬ 
tion,  and  application  use.  AFTOMS  has  four-tiers  with  each  tier  mapped  to  a  functional 
grouping. 

The  four  tiers  are  hierarchical,  with  centralized  control  coming  from  the  top  down.  Each  tier 
is  subordinate  in  function  and  responsibility  to  the  one  above  it.  The  functional  groupings  and 
their  related  AFTOMS  tier-level  organizations  are  listed  in  TABLE  A3-1  and  depicted  hier¬ 
archically  in  FIGURE  A3-3. 
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TABLE  A3-1.  AFTOMS  FUNCTIONAL  GROUPINGS 
AND  RELATED  TIER-LEVELS 


FUNCTION 

TIER 

ORGANIZATION 

General  Administration 

1 

AFTOMA 

Acquisition  and  Production 

2 

TOMA 

Ordering  and  Distribution 

3 

CTODO 

Application  Use 

4 

Work  Areas 

•  Tier  1 :  Air  Force  Technical  Order  Management  Administration  (AFTOMA )  - 
This  top  tier  is  a  single  organization/facility  within  the  Air  Force  that  is  re¬ 
sponsible  for  the  demonstration,  implementation,  and  management  of  AF¬ 
TOMS.  The  AFTOMA  establishes  Air  Force-wide  TO  policy  and  stan¬ 
dards  and  provides  coordination  between  Air  Force  commands  and  all 
participating  organizations  and  users  of  AFTOMS. 

•  Tier  2:  Technical  Order  Management  Agency  (TOMA )  -  This  tier  consists  of 
multiple  TOMAs,  each  of  which  is  responsible  for  the  acquisition,  planning, 
development  and  maintenance  of  TO  suites  for  weapon  systems,  commodi¬ 
ties,  or  specialized  equipment  sets.  Although  specific  system  related  TO 
duties  are  delegated  to  subfacilities  called  Technical  Order  Centers 
(TOCs),  the  TOMA  provides  the  overall  management  for  all  TOC  func¬ 
tions.  TOC  functions  will  be  supported  by  Materiel  Management  Agencies 
(MM_R)  for  TO  content  change  control,  and  TO  regional  data  centers  for 
distribution.  It  is  expected  that  during  development  of  a  new  weapon  sys¬ 
tem  or  a  major  modification  of  an  existing  system,  a  development  TOMA 
will  exist  to  acquire  and  develop  new  TOs. 

•  Tier  3:  Consolidated  Technical  Order  Distribution  Office  (CTO DO)  -  The 
third  tier  represents  service  organizations/facilities  located  at  each  base 
(geographic  location)  that  provide  centralized  TO  ordering  and  distribu¬ 
tion  services  for  an  entire  base,  regardless  of  its  command  orientation.  The 
CTODO  is  a  specialized  facility,  which  maybe  staffed,  managed,  and  oper¬ 
ated  under  either  AFTOMA  or  MAJCOM  control. 

•  Tier  4:  Work  Areas  (WAs)  -  Work  Areas  represent  end  user  communities  re¬ 
quiring  TOs  for  the  performance  of  their  mission  objective.  Work  Areas 
consist  of  using  command  personnel  and  are  not  managed  by  the  AFTO- 
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MA.  Examples  of  Work  Areas  are:  wing,  squadron,  shop,  office,  single 
user,  and  the  aircraft  itself. 
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FIGURE  A3-3.  AFTOMS  TIERS 

TOCs  and  data  support  centers,  subfacilities  within  the  tiers,  are  established  to  consolidate 
some  staffing  and  equipment  requirements  for  common  functions,  and  add  operational  effi¬ 
ciency  to  the  system  by  limiting  unnecessary  fragmentation.  TOCs  at  Tier  2  are  subfacilities 
of  an  ALC  regional  center. 

Each  TOMA/TOC  is  responsible  for  the  management  (i.e.,  acquisition,  planning,  develop¬ 
ment,  distribution,  and  updating)  of  the  complete  suite  of  TOs  for  a  single  weapon  system.  It 
must  be  emphasized  that  the  TOC’s  responsibility  for  the  complete  suite  of  weapon  system 
TOs  is  a  major  departure  from  the  existing  organization.  Currently,  TOs  for  a  weapon  system 
are  the  responsibility  of  several  ALCs,  each  with  a  different  subsystem  specialty.  In  the  To-Be 
concept,  the  TOMA/TOC  needs  to  acquire  and  distribute  all  TOs  for  a  specified  weapon  sys¬ 
tem  regardless  of  the  source  organization.  Each  weapon  system  will  then  be  supported  by  a 
single  TOC,  which  has  all  TOs  (of  whatever  type)  in  one  location  and  a  clear  mandate  to  man¬ 
age  the  TOs  of  that  weapon  system. 

Since  weapon  systems  share  many  common  equipment  items,  such  as  engines  and  avionics, 
there  will  be  a  need  to  create  TOCs  specializing  in  these  commodities.  TOMA  Commodity 
TOCs  (CTOCs)  would  eliminate  the  duplication  of  effort  that  would  occur  if  each  weapon 
system  TOC  managed  its  own  commodity  TO  inventory.  A  weapon  system  TOC  will  need  to 
acquire  commodity  TOs  directly  from  their  respective  TOCs.  The  weapon  system  TOC  will 
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then  place  these  commodity  TOs  into  its  suite  for  base  distribution.  Commodity  TOCs  will 
not  distribute  directly  to  the  CTODOs  but  only  to  weapon  system  TOCs  requiring  that  com¬ 
modity  TO.  However,  all  other  functions  (acquisition,  management,  production,  etc.)  remain 
the  responsibility  of  the  TOM  A/CTOC.  In  addition  to  weapon  system  and  commodity  TOCs 
there  will  also  be  TOCs  to  support  non-weapon  system  related  TOs  for  such  items  as  support 
vehicles,  policy  and  procedures,  indices,  etc.  The  AFTOMA  will  have  a  non-weapon  system 
TOC  to  support  its  administrative  TO  requirements.  Each  ALC  will  therefore,  house  a  mix 
of  TOMA/TOCs  each  with  its  own  TO  responsibilities.  The  types  of  TOCs  defined  and  their 
responsibilities  are  listed  in  TABLE  A3-2. 

TABLE  A3-2.  TECHNICAL  ORDER  CENTERS  AND  RESPONSIBILITIES 


TYPE 

TECHNICAL  ORDER 
RESPONSIBILITY 

DISTRIBUTES  TO: 

Weapon  System  TOC  (WSTOC) 

All  TOs  for  a  major  weapon 
system  (e.g.,  F-16,  B-1B) 

CTODOs 

Commodity  TOC  (CTOC) 

Subsystem  TOs  (e.g., 
pneudraulics,  engines) 

Weapon  System 
TOCs  (WSTOCs) 

Non-Weapon  System  TOC 
(NWSTOC) 

Remaining  TOs  (e.g., 
policy,  support  vehicles, 
equipment,  offices  systems) 

CTODOs 

Each  of  the  top  three  tiers  contains  distributed  and  centralized  data  center  facilities  designed 
to  provide  computer  services/resources  at  each  physical  location.  For  tier-level  organiza¬ 
tional  processing,  communications,  production  and  distribution  at  Tier  2,  centralized  facili¬ 
ties  are  appropriate,  and  consist  of  several  different-range  computers,  storage  capabilities 
and  printers  networked  via  a  Local  Area  Network  (LAN),  such  as  the  AFLC  LAN.  Each  TOC 
has  its  own  LAN-based  workstations  which  are  bridged  to  the  ALC  data  center.  Since  CTO¬ 
DOs  will  support  base-level  requirements,  the  configuration  of  their  data  centers  will  match 
required  capacities  and  support  levels.  All  CTODO  data  centers  will  need  to  provide  admin¬ 
istrative  processing,  TO  storage,  high  speed  printing,  and  communication  to  Tiers  1  and  2. 
Configurations  will  range  from  LAN-based  workstation  super-micro  to  mini-computer  sys¬ 
tems,  file  servers,  and  high-speed  laser  printers.  FIGURE  A3-3  shows  the  relationship  of 
subfacilities  within  the  tier  level  organizations. 

A3. 4.3  Information  Flows 

Top-down  data  flow  through  the  four  tiers  of  AFTOMS  is  controlled  by  the  AFTOMA  and 
the  associated  hierarchy.  The  AFTOMA  maintains  a  list  of  all  active  TOMA/TOCs  and  their 
associated  weapon  system  responsibilities.  Therefore,  the  AFTOMA  is  ideally  positioned  to 
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be  the  control  point  for  TO  distribution  and  authorization.  Once  TO  requests  are  registered 
by  Work  Area  users  in  Tier  4,  information  flows  up  to  the  AFTOMA  at  Tier  1  and  the  re¬ 
sponse  flows  down  through  the  tiers  until  it  returns  to  Tier  4.  This  arrangement  provides  cen¬ 
tralized  control  and  distribution  management. 

Work  Areas  request  information  in  the  form  of  task  definition  profiles  from  their  CTODO 
which,  in  turn,  sends  the  request  to  AFTOMA.  The  AFTOMA  either  responds  to  a  request 
directly  or  distributes  the  request  to  a  specific  TOMA/TOC  (Tier  2).  TOCs  may  then  pass 
requested  data  (usually  TOs)  back  to  the  CTODO  for  distribution  to  the  Work  Area.  It  is 
important  to  note  that,  in  this  top-down  flow  strategy,  CTODOs  do  not  request  information 
directly  from  TOCs.  The  CTODO,  therefore,  need  not  know  the  location  of  TOs.  This  sim¬ 
plifies  the  ordering  process,communications  paths,  and  allows  AFTOMA  flexibility  in  assign¬ 
ing  TOMA/TOC  responsibilities. 

FIGURE  A3-4  shows  the  main  information  path  flows  from  Work  Area  to  CTODO,  CTO¬ 
DO  to  AFTOMA,  AFTOMA  to  TOMA/TOC,  and  TOC  to  CTODO. 


FIGURE  A3-4.  AFTOMS  INFORM AnON  FLOW 
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A3.4.4  Interconnectivity 

The  flow  of  information  requires  communication  paths  that  meet  the  functional  demands  of 
*he  system  to  be  defined.  The  AFTOIviS  concept  builds  upon  the  current  implementation  of 
LANs  taking  place  in  the  Air  Force.  Since  the  AFTOMA  and  TOMA/TOCs  are  expected  to 
reside  at  ALCs,  the  workstations  and  gateways  to  the  ALC  data  centers  will  be  supported  by 
the  AFLC  LAN.  Local  base  communications  at  the  CTODO  (required)  and  Work  Areas  (op¬ 
tional)  will  be  provided  by  Unified  Local  Area  Network  Architecture  (ULANA)  specified 
LANs. 

FIGURE  A3-5  shows  the  main  points  of  interconnection  and  projected  communication  re¬ 
sources.  Transfer  of  complete  suites  of  TOs  to  the  bases  requires  media  exchange;  for  this  type 
of  bulk  data  transfer  optical  disc  is  recommended.  Individual  TO  transfer  among  TOCs  and 
the  SPO/M  AJCOM/'Contractor  community  will  be  via  the  wide  area  Defense  Data  Network 
(DDN)  dedicated  line  and  media  exchange.  Communication  of  information  other  than  TOs, 
such  as  change  requests  and  user  profiles,  will  be  via  interactive  transaction  traffic,  best 
served  by  a  Wide  Area  Network  (WAN)  such  as  the  DDN. 
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FIGURE  A3-5.  PROJECTED  COMMUNICATION  RESOURCES 
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A3.4.5  Major  Functionality 

In  establishing  the  functional  requirements  of  the  AFTOMS  system,  the  infrastructure  was 
designed  to  serve  the  management  and  distribution  of  TOs  regardless  of  their  type.  All  TOs. 
whether  Type  A,  B,  C,  or  their  variants,  require  a  system  that  can  provide  the  core  activities  of 
acquiring,  archiving,  cataloging,  distributing,  and  change  management.  These  activities  were 
mapped  to  the  AFTOMS  To-Be  concept  according  to  the  following  six  basic  functions: 

•  User  Profile  Registration  and  Maintenance; 

•  TO  Cataloging  and  Archiving: 

•  Master  Catalog  Maintenance; 

•  Distribution; 

•  TO  Planning,  Development,  and  Review;  and 

•  Change  Management. 

When  TO  data  is  brought  into  the  system  in  digital  form,  the  AFTOMS  system  functions 
should  be  similar  for  all  TOs  to  make  the  system  operationally  simple.  Paper  TOs  (Type  A), 
designated  for  AFTOMS  automation,  will  be  scanned  and  brought  into  the  system  as  digital, 
page-oriented  TOs  (Type  B).  Pageless  Type  C  TOs,  which  will  be  delivered  in  specialized 
digital  form,  should  share  the  common  system  functions  provided  for  Type  B,  except  that  they 
may  require  different  software  processing.  From  a  high-level  system  perspective,  the  differ¬ 
ence  between  TO  types  remains  functionally  transparent  until  actual  distribution  to  a  work¬ 
station.  Due  to  the  difference  in  delivery  formats,  Type  B  TOs  will  require  workstations  con¬ 
figured  with  hardware  and  software  that  enable  the  user  to  display,  scroll,  and  print  TO  pages, 
whereas  full  support  of  Type  C  TOs  will  require  specialized  delivery  systems. 

FIGURE  A3-6  is  a  flowchart  that  shows  the  system  functions  shared  by  all  digital  TOs.  This 
use  of  common  integrated  functions  to  provide  core  applications  will  eliminate  automation  of 
isolated  functionality.  In  addition,  since  the  system  is  functionally  modular,  hardware  and 
software  updates  to  any  given  function  can  be  made  without  disrupting  or  replacing  the  sys¬ 
tem  as  a  whole.  Until  their  withdrawal,  paper  TOs  (Type  A)  that  are  not  converted  to  digital, 
page-oriented  TOs  (Type  B)  will  be  assigned  to  TOCs  to  be  ordered,  cataloged,  and  distrib¬ 
uted  through  use  of  the  AFTOMS  common  functional  applications. 
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FIGURE  A3-6.  COMMON  SYSTEM  FUNCTIONS 


A3.4.6  Concept  Highlights  &  Benefits 

In  summary,  this  AFTOMS  To-Be  concept  supports  an  implementation  strategy  that  in 
volves: 

•  Capturing  Type  A  TOs  on  a  limited  and  economical  basis  by  using  scanners; 

•  Using  lype  B  TOs  in  the  short  term; 

•  Introducing  Type  C  TOs  in  a  later  phase  once  the  Type  C  operational  sup¬ 
port  requirements  are  better  understood; 

•  Using  new  technology  for  scanning,  cataloging,  storing,  and  retrieving  in¬ 
formation; 

•  Distributing  TOs  to  CTODOs  and  automated  WA  users  via  optical  disks; 

•  Supporting  sophisticated  entry,  modification,  and  on-line  retrieval  capa¬ 
bilities; 


•  Supporting  efficient  document  management; 

•  Distributing  information  based  on  profiles  of  individual  user  groups; 

•  Storing  all  types  of  information  (numeric,  textual,  pictorial,  and  others)  in  a 
unified  manner; 

•  Preparing  TOs  concurrently  during  the  development  of  weapon  systems 
with  review  of  TOs  in  progress;  and 

•  Establishing  modified  organizational  and  operational  procedures. 

The  AFTOMS  approach  will  produce  many  long-term  benefits  for  the  Air  Force  including 
increased  weapon  system  availability,  reduced  costs,  and  increased  mission  effectiveness. 
AFTOMS  provides  the  flexibility  needed  to  support  the  more  complicated  weapon  systems  of 
the  future.  Specifically,  AFTOMS  will: 

•  Reduce  overall  cost  of  TO  acquisition,  distribution,  and  maintenance; 

•  Improve  the  timeliness,  accuracy,  completeness,  and  currency  of  TOs; 

•  Provide  a  single  Air  Force  adminstrating  agency  which  will  have  optimal 
management  responsibility  for  the  entire  TO  process  and  all  TO  types; 

•  Provide  specific  management  responsibility  for  suites  of  related  TOs  by 
weapon  system,  commodity,  or  other  classification; 

•  Provide  clear  lines  of  authority'  and  accountability  for  all  TO  functional  ac¬ 
tivities;  and 

•  Enhance  control  and  impose  standardization  across  TOs,  especially  at  the 
stage  of  receipt  from  contractors. 
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SECTION  Bl: 

Management  Of  Distributed  User  Functionality 


Bl.l  SCOPE  AND  RELEVANCE 


The  AFTO  MS  Automation  Plan,  dated  February  1988,  contains  a  concept  of  the  Technical  Or¬ 
der  To-Be  System.  The  intention  of  the  AFTOMS  program  is  to  apply  automation  to  the  TO 
process  in  the  most  efficient  manner,  making  use  of  state-of-the-art  technology.  The  basis  of 
the  AFTOMS  concept  is  to  gain  maximum  benefits  from  automation,  by  automating  the  AF¬ 
TOMS  To-Be  Concept  rather  than  merely  applying  automation  to  the  As-Is  functions. 

The  To-Be  Concept  consists  of  seven  major  functions: 

•  Profile  Registration; 

•  Acquisition; 

•  Cataloging/Repositing; 

•  Distribution; 

•  Change  Management; 

•  Management;  and 

•  Conversion. 

The  AFTOMS  Automation  Plan  identified  three  additional  program  phases  beyond  To-Be 
development  to  fully  deploy  AFTOMS: 

•  Initial  Development  Phase  -  Issue  an  RFP,  perform  source  selection  prepara¬ 
tion  and  evaluation,  and  award  the  contract; 

•  Final  Development  Phase  -  Build  and  deploy  a  Pilot  System;  and 

•  Deployment  Phase  -  Deploy  AFTOMS  Air  Force-wide. 

FIGURE  Bl-1  depicts  a  representation  of  the  depth  of  planning  and  investigation  that  was 
applied  to  develop  the  To-Be  Concept.  An  entire  level  of  detail,  described  in  the  lowest- 
level  rectangle,  was  not  addressed  due  to  the  early  stage  of  the  effort.  However,  as  the  pro¬ 
gram  proceeded  into  the  next  phase  (Initial  Development),  it  became  necessary  to  address 
specific  issues  more  fullv  at  that  next  level  of  detail  to  attain  the  proper  level  of  thoroughness 
for  completion  of  the  Proof-of-Concept  (POC)  activity. 

This  section  of  the  report:  reviews  the  major  functions  of  the  AFTOMS  To-Be  Concept 
(addressing  them  in  more  detail  as  needed  );  identifies  any  modifications,  restructuring,  add¬ 
ed  or  diminished  implementation  risks;  and  thereby  provides  an  overall  framework  for  the 
To-Be  concept  as  it  exists  at  the  completion  of  the  Initial  Development  Phase  of  AFTOMS. 
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FIGURE  Bl-1.  LEVEL  OF  DETAIL 


B1.2  STATE  OF  INTEGRATION  FEASIBILITY 
Bl.2.1  Profile  Registration 

In  the  To-Be  concept.  Profile  Registration  was  envisioned  as  a  simplified  approach  for  order¬ 
ing  and  distributing  TOs.  From  a  functional  and  integration  point  of  view.  Profile  Registra¬ 
tion  is  closely  coupled  with  Distribution,  Cataloging,  Repositing,  and  Management.  Storing 
TO  content  and  TO  management  information  in  one  database  for  access  by  other  functions  is 
indeed  viable.  The  types  and  amount  of  information  that  need  to  be  stored  for  effective  distri¬ 
bution  is  approximately  what  was  planned  in  the  concept,  thus  keeping  it  simple  for  the  user 
community. 

Bl.2.2  Acquisition 

In  the  To-Be  concept,  delivery  of  TOs  was  expected  to  be  in  accordance  with  MIL-STD  1840. 
There  has  been  no  change  in  this  expectation.  However,  there  is  considerable  concern  over 
subsets  of  MIL-STD  1840,  most  notably  the  MLL^M  28001-based  employment  of  the  Stan¬ 
dard  Generalized  Markup  Language  (SGML).  Use  of  SGML  requires  availability  of  Docu¬ 
ment  Type  Definitions  (DTD),  Document  Instance  (DI)  subsets  of  DTDs,  Output  Specifica¬ 
tions  (OS),  and  Formatting  Output  Specification  Instances  (FOSI).  The  net  assessment  is 
that,  while  schedules  for  development  of  SGML  components  are  of  concern,  the  approach  is 
technologically  feasible. 

Bl.2.3  Cataloging/Repositing 

In  the  area  of  cataloging,  the  concept  has  been  greatly  expanded  and  enhanced  to  allow  for 
much  additional  functionality  in  distribution  and  delivery  (specifically,  on-line  delivery).  In 
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the  initial  To-Be  concept,  the  main  purpose  of  the  cataloging  function  was  to  store  a  set  of 
descriptive  fields  of  information  in  a  database,  to  be  used  for  storing  and  retrieving  TOs. 
During  the  POC  effort,  it  became  apparent  that  the  maintenance  and  operational  user  com¬ 
munity  (located  primarily  at  Tier  4)  needed  delivery  of  the  TO  information  in  many  alternate 
and  more  sophisticated  forms,  as  opposed  to  merely  printed  or  displayed  pages  on  a  worksta¬ 
tion  screen.  For  example,  TOs  were  not  always  used  individually  but  often  were  used  in  con¬ 
junction  with  other  TOs  to  complete  a  task  whose  technical  information  spanned  several  TOs. 
Various  data  was  configuration-specific  and  suited  to  a  specific  maintenance  experience  lev¬ 
el.  Many  other  similar  data-usage  requirements  arose  that  could  increase  the  productivity  of 
the  Tier  4  user  if  the  presentation  of  TO  data  was  suitably  customized. 

It  was  discovered  that  if  the  cataloging  function  was  expanded  to  add  and/or  generate  addi¬ 
tional  descriptive  information  about  a  TO  or  relationships  across  TOs,  then  such  tagging  in¬ 
formation  could  be  embedded  within  the  distribution  and  used  by  the  delivery  system  to  offer 
the  users  much  additional  functionality. 

The  Change  Management  function  could  also  benefit  from  catalog  tagging.  During  the  POC 
effort,  it  was  found  that  changes  in  one  TO  often  caused  changes  to  related  TOs.  By  cross- 
referencing  TOs  in  a  suite  using  catalog  tagging,  related  TOs  can  be  found  efficiently  and 
accurately  to  allow  for  all  changes  spawned  by  a  change  request. 

Bl.2.4  Distribution 

In  the  original  concept,  the  assumption  was  made  that  TOs  would  be  distributed  on  a  system- 
by-system  basis.  This  assumption  was  based  on  two  major  premises: 

•  All  TOs  associated  with  a  weapon  system  would  be  of  a  specific  type  (paper, 
digital  page  image,  interactive  digital,  etc.);  and 

•  A  single  organizational  element  would  manage  and  control  all  TOs  associated 
with  the  system. 

An  analysis  of  these  premises  indicated  both  were  incorrect.  Practically  all  new  and  emerg¬ 
ing  weapon  systems  will  consist  of  a  variety  of  TO  types,  with  a  variety  of  AFLC  and  AFSC 
organizations  responsible  for  their  management  and  control.  Further,  a  determination  was 
made  that  the  suite  of  TOs  supporting  a  weapon  system  consists  of  system-unique  TOs  (e.g., 
Bl,  F16,  etc.),  support  equipment  TOs  (e.g.,  power  carts,  maintenance  stands,  etc.),  and  com¬ 
modity  TOs  (e.g.,  altimeter,  radio,  engine,  etc.). 

The  concept  was  expanded  to  take  into  account  both  realities.  AFTOMS  will  provide  a  single 
point  management  responsibility,  called  a  Technical  Order  Center  (TOC),  for  each  system. 
The  TOC  is  a  sub-element  of  a  TOMA  The  TOC's  role  is  to  manage  and  distribute  its  mixed 
suite  of  TOs.  The  TOCs  which  manage  commodity  and  support  equipment  TOs  will  only 
distribute  them  to  the  system-specific  TOCs  for  incorporation  into  complete  weapon  system 
TO  suites  and  subsequent  distribution  to  users. 
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The  concept  also  entailed  a  two-tiered  distribution  strategy.  The  first  level  was  full  suite  dis¬ 
tribution  from  Tier  2  (TOMA)  to  Tier  3  (CTODO).  The  second  level  was  customized  distri¬ 
bution,  based  on  Work  Area  profiles,  from  Tier  3  (CTODO)  to  Tier  4  (Work  Area).  The 
simple  form  of  second-level  distribution  is  paper  or  digital  delivery  to  Tier  4  users.  However, 
in  most  instances,  a  more  complex  environment  exists  at  Tier  4.  At  this  time,  a  standardized, 
proven  base-level,  digital  TO  delivery  and  presentation  system  has  not  been  established. 
Several  delivery  systems,  such  as  ITDS,  IMIS,  etc.  will  exist  that  merge  TO  data  with  other 
technical  data,  and  then  deliver  the  information  to  users  in  a  more  integrated  fashion. 

An  AFTOMS  requirement  is  to  support  linkage  to  these  systems.  However,  AFTOMS  can¬ 
not  afford  to  develop  a  customized  interface  to  every  existing  and  future  system  at  Tier  4.  The 
initial  To-Be  concept  was  expanded  to  provide  a  standard  interface  (see  Section  B5,  Interface 
to  Other  Air  Force  Functions/Systems)  from  AFTOMS  (at  Tier  3)  to  other  base-level  sys¬ 
tems.  This  interface  will  control  a  two-way  flow,  receiving  profiles  and  change  requests  from 
Tier  4  and  delivering  TOs  anu  updates  of  TOs  to  Tier  4. 

Bl.2.5  Change  Management 

The  AFTOMS  To-Be  change  management  concept  focuses  on  a  change  request-based  pro¬ 
cessing  function  using  the  following  procedure: 

1.  Fill  out  an  AFT022  change  request  form  at  the  Work  Area  (Tier  4); 

2.  Forward  the  request  to  the  CTODO  (Tier  3)  for  consolidation  with  other  re¬ 
quests; 

3.  Route  the  request  through  the  Ai  .  OM  A  (Tier  1)  to  the  appropriate  TOMA/ 
TOC  (Tier  2)  for  review  and  approval  for  action;  and 

4.  Approve  authorization  for  any  changes  to  be  made. 

There  is  a  lengthy  quality  assurance  review  process  that  occurs  within  a  command  (Base  level 
and  Command  HQ)  before  the  change  request  is  reviewed  at  an  ALC.  This  part  of  the  pro¬ 
cess  was  not  accounted  for  in  the  initial  concept. 

After  a  detailed  look  at  this  review  process,  the  concept  has  been  expanded  to  accomodate 
automatic  routing  on  a  sequential  cycle,  based  on  profile  information,  to  all  review  partici¬ 
pants  at  command  level.  This  is  performed  without  the  need  for  paper  transfer  of  the  change 
request  and  transcribing  of  the  information  to  additional  forms.  In  fact,  the  user  filling  out  the 
request,  as  well  as  all  intermediate  reviewers,  do  not  have  to  fill  out  the  exact  replica  of  the 
AFT022  form.  This  can  be  left  until  the  last  review  step  and  then  automatically  generated  by 
AFTOMS,  thus  saving  a  significant  amount  of  time  and  tedious  effort  for  users  and  reviewers. 
After  command  level  review,  the  request  can  be  routed  to  the  AFTOMA  and  then  to  the  ap¬ 
propriate  TOMA/TOC  for  processing. 
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Bl.2.6  Management 


AFTOMS  is  primarily  a  management  system.  Paramount  to  its  success  is  having  access  to 
sufficient  amount  of  data  regarding  TOs,  users,  change  requests,  production  statistics,  sched¬ 
uling  and  tracking  information,  etc..  The  current  manual  system  is  slow  and  inefficient  be¬ 
cause  of  its  inability  to  make  this  type  of  database  available.  In  the  initial  To-Be  concept, 
these  data  management  functions  were  not  addressed  in  detail. 

After  understanding  the  details  of  the  existing  manual  system,  an  acute  awareness  developed 
for  the  need  to  incorporate  the  LMTOS  management  data  into  AFTOMS,  and  add  new  data 
for  effective  management  control.  Effective  interactive  functionality  and  proper  batch¬ 
generated  reports  are  essential  for  improved  operational  performance.  This  management 
data  must  interact  with  the  cataloging  information  and  document  management  data  to  help 
coordinate  all  of  the  AFTOMS  functions. 

Bl.2.7  Conversion 

There  are  over  150,000  Air  Force  TOs  in  existence  today.  Over  the  next  five  to  six  years  when 
AFTOMS  is  deployed,  only  a  small  percentage  of  new  TOs  will  enter  the  inventory  in  compar¬ 
ison  to  those  now  in  existence.  An  economically  and  operationally  successful  automated  TO 
process  is  dependent  upon  converting  as  many  TOs  as  possible  to  digital  form.  This  allows  for 
application  of  the  greatest  degree  of  automation  to  the  processing  of  TOs  in  the  downstream 
functions  of  distribution,  on-line  delivery,  and  change  management. 

In  the  initial  To-Be  concept,  several  conversion  strategies  were  presented.  Conversion  of 
Type  A  TOs  (paper)  to  Type  B  (digital),  and  delivery  of  those  TOs  to  AFTOMS  in  MIL-STD 
1840  is  the  most  desirable  alternative.  However,  it  is  also  the  most  challenging  alternative  for 
the  following  reasons: 

•  Converting  old  TOs  according  to  newly  specified  DTDs  and  OSs  requires  re¬ 
formatting; 

•  The  amount  of  trained  labor  needed  to  inspect  and  assure  that  the  integrity  of 
the  content  of  each  converted  TO  is  not  altered  is  significant; 

•  All  the  TOs  in  the  suite  need  to  be  converted  to  maximize  efficiency  in  the  dis¬ 
tribution  process;  and 

•  The  huge  volume  of  TOs  that  need  to  be  converted  means  a  sizable  investment 
both  in  time  and  dollars. 

Detailed  investigation  of  the  paper  TO  inventory  shows  TOs  having  inconsistencies,  stan¬ 
dardization  differences,  and  poor  publication  quality  (especially  in  older  TOs).  The  technolo¬ 
gy  to  automate  this  conversion  process  more  completely  is  progressing  and  presents  less  of  a 
problem  than  the  operational  issues  enumerated  above. 
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B1.3  PARTICULAR  INTEGRATION  APPROACHES  USED  IN  THE  DEMO  SYSTEM 

In  the  development  of  the  Demo  System,  the  main  thrust  was  to  acquire  application  software 
modules  and  integrate  those  modules  to  produce  the  desired  functionality.  The  main  activi¬ 
ties  in  the  Demo  System  were: 

•  Developing  interfacing  software  to  link  up  the  acquired  application  software 
modules; 

•  Developing  a  common  user  interface  style  to  make  the  integration  appear 
seamless; 

•  Customizing  and  enhancing  the  acquired  application  software  functionality  to 
support  AFTOMS  needs;  and 

•  Integrating  all  the  hardware,  software,  and  communications  components  into 
the  system. 

The  conceptual  architecture  of  the  Demo  System  is  shown  in  FIGURE  Bl-2. 

As  the  design  and  development  of  the  user  functionality  progressed,  a  key  point  continued 
to  surface.  To  implement  most  user  functions  (and  subfunctions),  it  was  necessary  to  draw 
on  a  combination  of  data  elements  that  resided  in  the  Relational  Data  Base  Management 
System  (RDBMS)  and  the  Document  Management  System  (DMS).  Multiple  sequential  steps 
existed,  in  both  access  and  update  transactions,  where  the  access  of  a  data  element  from  the 
RDBMS  became  an  input  parameter  or  link  to  the  DMS  in  a  succeeding  step.  In  fact,  a  very 
tight  coupling  existed  between  the  RDBMS  and  the  DBMS  to  provide  effective  data  manage¬ 
ment  within  AFTOMS.  Traditional  electronic  publishing  systems,  which  attempt  to  embed 
data  management  services  within  their  product,  do  not  have  a  rich  enough  set  of  data  manage¬ 
ment  services  to  support  the  robust  user  requirements  of  AFTOMS.  However,  when  coupled 
with  data  management  services  supplied  by  database  products,  the  desired  functionality  can 
be  supported. 

Another  related  type  of  issue  also  became  apparent.  There  is  a  very  tight  coupling  between 
additional  B  -I-  tagging  and  the  functionality  that  becomes  available  to  the  user  of  the  On-line 
Delivery  System  (ODS).  The  ODS  has  the  ability  to  provide  different  data  presentation  and 
hypertext  navigational  features  to  the  user.  However,  the  power  of  ODS  is  severely  limited 
unless  the  additional  tags  are  added  to  the  documents. 
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FIGURE  Bl-2.  DEMO  SYSTEM  CONCEPTUAL  ARCHITECTURE 


With  respect  to  tagging,  some  degree  of  flexibility  is  available.  When  additional  B+  tagging 
is  required,  appropriate  tags  can  be  added: 

•  While  the  TOs  are  being  prepared; 

•  During  the  Cataloging  process;  or 

•  During  the  Change  Management  process,  if  additional  ODS  functionality  is  de¬ 
sired. 

While  testing  and  debugging  the  ODS,  an  additional  branch,  link,  reference,  etc.  capability 
was  observed  that  would  make  a  displayed  TO  more  usable  by  making  it  easier  to  locate  and 
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retrieve  related  information.  To  effect  this  capability,  the  addition  and/or  modification  of 
a  few  tags  at  the  tagging  step  was  required.  When  AFTOMS  is  deployed,  it  is  possible  that 
a  significant  number  of  change  requests  will  address  tagging  changes  as  opposed  to  requests 
for  content  changes.  This  tagging  flexibility  allows  introducing  additional  display  capability 
long  after  the  TOs  are  authored  and  cataloged  in  the  inventory. 

B1.4  RISK  ASSESSMENT 

After  developing  the  next  level  of  detail  shown  in  Figure  Bl-1,  the  AFTOMS  To-Be  concept 
continues  to  be  viable,  especially  at  the  major  functional  level.  The  concept  is  robust  enough 
to  support  detailed  modifications  if  needed. 

The  AFTOMS  Demo  System  reinforces  the  viability  of  the  concept  with  respect  to  correct  and 
tightly  coupled  functions.  Also,  the  user  interfaces  demonstrated  in  the  AFTOMS  Demo  Sys¬ 
tem  appear  to  match  the  needs  of  all  major  classes  of  users:  data  managers,  maintenance  and 
operations  users,  and  publications  personnel. 

Within  some  functions,  the  current  unavailability  of  specific  details  presents  the  highest  risk. 
The  major  residual  risks  are  present  in  the  following  areas: 

•  The  ability  to  perform  conversion  on  entire  suites  of  TOs; 

•  Availability  of  DTDs  and  OSs  to  assist  the  conversion  process; 

•  Integrating  support  TOCs  and  commodity  TOCs  with  system  TOCs  for  effec¬ 
tive  TO  suite  distribution;  and 

•  Defining  a  standard  AFTOMS  interface  to  base-level  systems. 

B1.5  RISK  ABATEMENT 

The  following  abatement  activities  should  be  performed  to  minimize  the  above  risks: 

•  Institute  a  pilot  conversion  activity  on  a  representative  suite  of  TOs  as  soon  as 
possible; 

•  Obtain  continuous  feedback  on  user  interface  details  and  AFTOMS  function¬ 
ality  from  potential  users  via  Demo  System  review; 

•  Update  and  extend  the  Demo  System  to  reflect  user  feedback; 

•  Use  the  Demo  System  as  a  training  and  educational  tool;  and 

•  Incorporate  Demo  System  concepts  into  the  System  Operational  Require¬ 
ments  Document  (SORD)  and  Functional  Description  (FD)  to  ensure  a  syn¬ 
chronized  view  of  AFTOMS  functionality. 
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SECTION  B2: 

Handling  and  Conversion  of 
Heterogeneous  Technical  Order  Data 


B2.1  BACKGROUND 


This  section  identifies  and  analyzes  the  problems  of  managing  the  entire  mixed  TO  inventory 
in  the  Air  Force.  It  includes  TOs  currently  in  existence,  TOs  that  are  under  development,  and 
TOs  that  will  be  generated  and  acquired  in  the  near  and  long  term  future.  Three  major  topics 
are  discussed: 

•  Management  of  Mixed  Technical  Order  Suites  -  This  topic  evaluates  the  cur¬ 
rent  and  near-term  makeup  of  the  TO  inventory,  and  the  management  ap¬ 
proach  needed  to  manage  it; 

•  Conversion  of  Technical  Orders  -  This  topic  evaluates  conversion  of  the  cur¬ 
rent  TO  inventory  in  paper  form  to  digital  form,  if  technically  and  economically 
feasible,  to  take  advantage  of  the  management  techniques  proposed  in  the  first 
topic; 

•  Classified  Technical  Orders  -  This  topic  adds  the  complex  issue  of  classified 
data  to  the  previous  topics  since  a  portion  of  the  TO  inventory  is  classified  at 
various  levels.  Classified  TOs  must  be  managed  as  well  as  unclassified  TOs. 

B2.2  MANAGUMEN  I  OF  MIXED  TECHNICAL  ORDER  SUITES 

This  section  describes  the  realities  of  the  current  and  near-term  makeup  of  the  TO  inventory' 
by  TO  type  and  the  management  approach  needed  to  manage  this  heterogeneous  inventory. 

B2.2.1  Scope  and  Relevance 

AFTOMS  is  an  all-inclusive  TO  management  system  for  the  Air  Force.  Currently,  the  inven¬ 
tory  contains  approximately  150,000  TOs  and  is  rapidly  increasing  as  newer  and  more  sophis¬ 
ticated  weapon  systems  are  developed.  It  is  unrealistic  to  implement  a  management  tech¬ 
nique  to  manage  each  and  every  TO  as  a  separate  entity.  Also,  it  is  operationally  unrealistic  to 
apply  a  technique  that  tries  to  manage  the  entire  inventory  as  one  enormous,  homogeneous 
entity. 

A  strategy  is  required  to  divide  the  inventory  naturally  into  TO  suites  (groups  of  related  TOs); 
and  then  a  consistent  management  technique  needs  to  be  applied  to  each  suite.  The  strategy- 
chosen  is  one  that  divides  the  inventory  on  a  weapon  system  basis  supported  by  reusable  com¬ 
modity  TO  sub-suites.  It  should  be  noted  that  the  term  “weapon  system”  refers  to  major  sys¬ 
tems  in  the  Air  Force  (e.g.,  F16,  C5,  BIB,  ATF).  These  weapon  systems  are  not  the  only  sys¬ 
tems  generating  TOs;  other  TOs  are  written  to  cover  administrative  procedures,  support 
equipment,  and  commodity  subsystems  used  in  several  weapons  systems.  (In  this  report,  tech¬ 
nical  issues  and  solutions  will  be  presented  in  the  context  of  major  weapons  systems  since  they 
require  the  most  complex  management  strategy.) 

TOs  within  the  framework  of  a  weapon  system  present  an  added  dimension  to  the  manage¬ 
ment  problem.  TOs  can  be  Type  A  (paper),  lype  B  (page-oriented,  digital),  or  Type  C  (inte- 
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prated,  interactive  data  in  digital  form).  If  consideration  is  given  to  a  weapon  system  suite  for 
a  medium-to-large  program,  there  is  a  high  probability  that  the  TO  suite  will  be  a  mixture  of 
all  types  of  TOs.  This  is  likely  to  continue  in  the  future  because  of  TO  reuse  (i.e.,  for  commo¬ 
dities).  Also,  if  an  assumption  is  made  that  Type  A  TOs  in  the  suite  have  been  converted  to 
Type  B  TOs,  then  a  mix  of  Type  B  and  Type  C  TOs  would  still  exist  requiring  TO  management 
as  an  entity. 

TOs  are  used  for  a  variety  of  purposes.  These  include  maintenance,  operations,  training,  sup¬ 
port,  etc.  However,  the  majority  of  TOs  in  a  weapon  system  suite  are  used  in  the  maintenance 
activity.  There  are  three  types  of  maintenance  activities  in  the  Air  Force: 

•  On-Equipment  (O-level); 

•  In-Shop  (I-level);  and 

•  Depot  (D-level). 

Each  of  these  maintenance  activities  for  a  weapon  system  program  has  separate  maintenance 
strategies  that  will  directly  affect  the  type  of  TOs  (B  or  C)  developed. 

TO  management,  which  is  the  primary'  function  of  AFTOMS,  includes  various  sub-functions: 

•  Authoring  (usually  performed  by  the  prime  contractor): 

•  Acquisition  (includes  verification): 

•  Cataloging  and  Repositing  (includes  cross-referencing  across  suites); 

•  Distribution: 

•  Change  Management  (includes  change  authoring):  and 

•  Usability'  (user  level  responsibility). 

In  considering  the  above  dimensions  along  with  the  realization  that  there  are  many  weapon 
system  programs  (approximately  50),  the  complexity'  of  the  management  problem  that  con¬ 
fronts  AFTOMS  is  evident.  However,  the  premise  that  AFTOMS  is  the  all-inclusive  TO 
management  system  for  the  Air  Force  mandates  that  it  must  perform  the  TO  management 
function  for  all  programs.  For  efficiency,  it  must  do  so  in  as  standardized  a  manner  as  possi¬ 
ble.  Both  requirements  are  critical  to  the  success  of  AFTOMS. 

B2.2.2  Understanding  the  Different  TO  Types  (A,  B,  B-,  B  +  ,  C) 

The  following  list  identifies  and  describes  each  TO  type: 

•  Type  A:  All  TOs  that  currently  exist  in  the  Air  Force  inventory  or  will  be  deliv¬ 
ered  in  paper  form; 

•  Type  B:  Page-oriented  TOs  in  digital  form; 

•  Type  B-:  Page-oriented  TOs  in  digital  image  form  (text  and  graphics  are  in  ras¬ 
ter): 
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•  Type  B  + :  Page-oriented  TOs  in  digital  form,  containing  tagging  information 
to  allow  electronic  display  of  variant  documents  with  efficient  access  to  internal 
and  external  reference  points;  this  makes  related  information  (graphics,  tables, 
other  TOs,  etc.)  easily  retrievable;  and 

•  Type  C:  Integrated,  interactive  data  in  digital  form  containing  tagging  informa¬ 
tion  to  allow  efficient  access  via  electronic  display  to  required  data. 

FIGURE  B2-7  is  a  high-level  summary  of  the  characteristics  of  the  different  TO  types. 
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FIGURE  B2-7.  THE  AFTOMS  DOCUMENT  TYPE  CONTINUUM 

Type  B  +  and  Type  C  have  the  same  basic  similarities  and  differences.  A  major  difference 
exists  in  the  authoring  approach.  Type  B+  authoring,  or  document  authoring,  is  performed 
in  the  traditional  manner  for  creating  technical  manuals.  In  this  approach,  engineers  and 
technical  writers  organize  their  thoughts  and  ideas,  and  write  them  in  a  narrative  or  descrip¬ 
tive  manner  that  approximates  the  sequential  order  that  is  most  usable  to  the  reader.  This  is 
called  the  primary  view.  Additional  views  could  be  generated  from  the  primary  view  by  add¬ 
ing  more  tagging  information  with  such  qualifiers  as  configuration,  skill  level,  security  access, 
etc.  However,  the  primary  view  retains  the  order  in  which  it  was  authored  (document  form). 
The  primary  view  is  also  the  manner  in  which  the  information  is  stored  in  the  data  repository. 
Therefore,  some  ievel  of  data  redundancy  is  inevitable,  although  major  tagged  components 
are  reusable. 
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To  reduce  data  redundancy  to  a  minimum,  Type  C  information  is  authored  in  a  different  man¬ 
ner.  There  is  not  a  concept  of  a  primary  view  and  certainly  not  one  of  sequential  authoring  of 
information.  Views  are  created  by  linking  together  components  of  information  (i.e.,  para¬ 
graphs,  warnings,  tables,  diagrams)  that  exist  in  the  database.  These  components  are  au¬ 
thored  or  created  independent  of  any  predefined  view.  They  are  also  authored  with  the  idea 
of  becoming  reusable  information  elements  within  the  discipline  in  which  they  will  be  used 
(i.e.  maintenance  strategy)  1  he  components  are  stored  in  the  database  and  can  be  selected 
for  insertion  into  one  or  more  view's;  these  views  are  created  after  components  are  generated. 
This  Type  C  authoring  process  is  referred  to  as  database  authoring.  The  Type  C  authoring 
process  creates  more  difficulties  than  the  Type  B+  authoring  process.  Some  of  these  major 
difficulties  are: 

•  Cultural  changes  that  writers  experience; 

•  Shortage  of  adequate  tools  and  systems  to  assist  writers  in  generating  reusable 
text  and  illustration  components;  and 

•  Locating  appropriate  existing  components  for  compilation  into  TGs  without 
increasing  data  redundancy  in  the  database. 

Similar  authoring  issues  apply  during  change  management,  some  of  which  will  be  performed 
organically  by  the  Air  Force. 

Whether  the  authoring  process  is  document-oriented  or  database-oriented,  both  ap¬ 
proaches  provide  the  capability  to  create  equivalent  predefined  multiple  views  from  the  same 
information  base.  The  Type  C  approach,  which  closely  resembles  true  hypertext,  is  far  more 
dynamic  in  the  number  and  types  of  different  views  which  can  be  created.  The  Type  B+  ap¬ 
proach  is  oriented  toward  a  smaller  but  adequate  number  of  predefined  views  that  key  off  the 
primary  view.  In  the  Air  Force  environment,  it  is  important  to  have  only  predefined  views 
accessible  by  users  to  ensure  safety,  precision,  and  regulatory  control  over  critical  and  life- 
threatening  maintenance  and  operating  procedures.  Both  approaches  (Type  C  and  Type 
B  + )  can  be  used  to  create  the  views  that  the  Air  Force  requires.  However,  when  the  Type  C 
database  is  constrained  to  such  controlled  views  (resulting  in  Type  C-),  much  of  the  flexibility 
and  benefit  of  Type  C  goes  unused. 

A  related  issue  to  authoring  is  verification.  Verification  is  the  organic  process  that  is  used  to 
check  the  clarity,  completeness  and  usability  of  views  to  complete  a  specific  task.  Information 
»n  the  Type  B+  process  is  delivered  as  a  document  in  its  primary  view.  Verification  is  per¬ 
formed  by  traversing  the  document  with  this  primary  view.  Subsequently,  all  additional  views 
are  checked  in  a  similar  manner. 

Verification  of  Type  C  data  is  a  more  complicated  process  that  has  two  steps.  Type  C  informa¬ 
tion  is  delivered  in  database  form.  However,  once  the  database  is  stored,  the  second  step  of 
the  verification  process  is  similar  to  Type  B+  verification  Every  predefined  view  must  be 
checked  for  correctness,  completeness,  and  clarity.  However,  before  the  views  can  be  veri- 
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fied,  the  individual  components  must  be  verified,  the  structure  and  composition  of  the  data¬ 
base  checked  to  ensure  that  all  linkages  between  components  and  views  are  correct  and  con¬ 
sistent.  and  view  access  limits  tested  to  ensure  that  only  authorized  views  can  be  accessed  at 
each  corresponding  level  of  maintenance.  Such  a  process,  while  possible  from  a  technical 
viewpoint,  will  be  complex,  time  consumming,  and  expensive. 

One  of  me  primary  goals  of  Type  C  is  the  elimination  of  redundant  information.  In  its  most 
optimum  form,  there  would  be  no  redundant  information  in  a  Type  C  database.  Since  views 
are  created  after  the  components  are  authored  by  stringing  the  components  together,  redun¬ 
dant  information  should  not  enter  the  database.  However,  Type  B+  authoring  consists  of 
creating  the  primary  view  and  reusing  the  components  as  additional  subset  views  are  created. 
Thus,  the  reduction  of  redundant  information  with  Type  B+  will  not  be  as  great  as  in  Type  C. 

Items  such  as  illustrations,  tables,  warnings,  cautions,  and  boilerplate  text  are  prime  examples 
of  components  that  can  be  reused  many  times  in  a  document  suite  or  database.  However,  with 
items  such  as  section  heads,  paragraph  text,  etc.,  the  issue  is  more  complex.  The  thoughts  or 
content  may  be  similar  but  not  exact,  since  paragraph  text  is  written  and  read  in  the  context  of 
what  preceded  it  in  the  view  stream.  There  will  be  other  costs  accrued  in  the  areas  of  author¬ 
ing.  verification,  etc.,  to  eliminate  this  additional  redundancy.  In  the  assessment  and  evalua¬ 
tion  of  some  of  the  typical  TO  suites  for  programs  like  the  F16,  C5.  etc.,  it  was  observed  that 
similar  information  existed,  but  only  a  minimum  amount  of  duplicate  information.  In  Type  C 
authoring,  redundancy  control  will  require  considerable  operator  discipline  as  the  pressure  of 
time  will  work  against  the  need  to  search  the  database  for  duplicates  or  near  duplicates. 

The  following  major  issues  exist  when  using  Type  B+  or  Type  C  authoring: 

•  How  to  author  and  manage  the  data  to  support  the  functionality  required  by  the 
users — The  largest  group  of  end  users  (maintenance  and  operations  personnel) 
are  not  concerned  with  the  amount  of  data  redundancy  or  the  method  used  in 
authoring,  acquiring,  managing,  or  changing  the  information.  These  functions 
are  transparent  to  them.  When  the  users  indicate  a  preference  for  Type  C  data, 
what  they  are  really  saying  is  that  they  need  multiple  views  into  the  data  base: 
and 

•  The  system  must  be  designed/developed  in  the  FY91-F}'93  time  frame  and 
deployed  in  the  FY93-FY95 period — Thus,  one  must  factor  in  the  pace  and  avail¬ 
ability  of  the  technology  components  needed.  Even  a  Type  B  +  system  has  nev¬ 
er  been  fully  developed  and  tested,  let  alone  a  more  sophisticated  Type  C  sys¬ 
tem. 

Factoring  all  of  this  information  into  the  decision  making  process,  the  strategy  for  managing  a 
heterogeneous  suite  of  TOs  is  evident.  If  Type  C  concepts  can  be  integrated  into  a  baselined 
Type  B  +  management  approach  without  preventing  or  slowing  down  a  full  Type  C  solution  in 
the  future,  maximum  functionality  and  flexibility  can  be  realized  with  minimum  risk. 


B2.2.3  Type  B  (B,  B-,  B  + )  Management  Approach 

TO  management  spans  the  functions  of  authoring,  acquisition,  cataloging,  repositing,  distri¬ 
bution,  change  management  and  usability  of  the  TOs.  In  this  section,  each  of  these  functions 
will  be  described  with  respect  to  the  Type  B  Management  Approach. 

AUTHORING 

Authoring  can  exist  in  the  contractor  environment  or  can  be  performed  organically.  It  will  be 
performed  in  the  traditional  manner  utilizing  current  electronic  publishing  systems.  Tagging 
of  the  data  can  be  accomplished  during  the  authoring  step  or  can  be  added  during  a  post¬ 
processing  stage.  Two  major  type  of  tags  exist:  structural  tags,  which  identify  the  components 
of  the  document  (i.e.,  titles,  section  heads,  paragraphs,  warnings,  etc.)  and  content  or  qualifi¬ 
er  tags  (i.e.,  configuration,  skill  level,  security  access,  etc.).  The  qualifier  tags  are  the  mecha¬ 
nisms  that  allow  users  to  obtain  Type  B  +  functionality'  from  Type  B  data.  The  Document  Type 
Definitions  (DTDs)  that  are  currently  under  development  in  the  Air  Force  will  support  both 
types  of  tagging.  Therefore,  the  content  or  qualifier  tags  can  be  entered  by  the  contractor 
during  authoring  and  acquired  by  the  Air  Force,  or  the  TOs  could  be  acquired  without  con¬ 
tent  tags  which  can  be  added  organically  at  a  later  date. 

ACQUISITION 

Acquisition  of  the  TOs  will  take  place  according  to  the  procedures  defined  by  the  CALS  pro¬ 
gram.  The  TOs  will  be  delivered  to  the  Air  Force  in  accordance  with  MIL-STD  1840.  The 
DTDs  will  be  the  official  document  types  that  these  TOs  will  be  checked  against.  These  DTDs 
will  support  all  Type  B  TOs  (B-,  B,  B  +  ). 

CATALOGING  AND  REPOSITING 

Once  the  TOs  have  been  acquired,  they  must  be  cataloged  and  stored  into  the  repository'. 
Cataloging  is  the  step  that  adds  relevant  identifying  information  on  the  TO  to  the  database.  If 
content  tagging  is  incomplete,  content  tags  will  be  added.  Thgs  to  support  branching  and  link¬ 
ing  to  other  TOs  within  the  system  suite  or  outside  the  system  suite  would  be  added  during  the 
cataloging  process.  Branches  and  links  that  occur  across  TOs  in  a  suite  provide  cross-refer¬ 
encing  information.  Tags  for  cross-referencing  also  can  be  added  during  the  cataloging  pro¬ 
cess. 

Another  major  part  of  cataloging  is  reducing  the  redundancy  of  information  within  the  data¬ 
base.  The  managers  of  the  TO  suite  can  identify  and  eliminate  the  redundant  information 
during  the  cataloging  process,  using  the  automated  capabilities  of  document  management 
systems.  When  cataloging  is  complete,  TOs  will  be  stored  in  the  repository. 

DISTRIBUTION 

A  key  element  of  the  management  strategy  is  dividing  the  inventory  on  a  weapon  system  basis. 
The  biggest  functional  beneficiary  of  this  approach  is  distribution.  A  bulk  media  distribution 
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of  the  entire  suite  is  the  primary  way  in  which  TOs  will  flow  from  the  TOMAs  to  the  CTODOs. 
All  TOs  acquired  in  Type  B  or  Type  B  +  form  already  will  be  in  the  proper  format  for  inclusion 
in  this  bulk  distribution.  However,  most  weapon  system  programs  have  a  portion  of  their  TO 
suite  in  Type  A  form.  These  TOs  can  be  image  scanned  into  Type  B-  form  to  be  included  in 
the  digital  distribution.  Since  AFTOMS  manages  all  TOs  in  the  inventory,  it  already  has  cata¬ 
loging  information  on  the  TOs  before  they  are  imaged  scanned.  After  scanning,  AFTOMS 
has  digital  page  representations  that  can  be  viewed  and  printed. 

CHANGE  MANAGEMENT 

The  core  technologies  needed  to  manage  TO  suites  effectively  are  Document  Management 
Systems  (DMS)  tightly  coupled  with  Relational  Database  Management  Systems  (RDBMS). 
Data  elements  such  as  change  requests,  authorization  forms,  versions,  revisions  of  TOs,  and 
scheduling  and  tracking  of  data,  all  work  together  to  support  automated  change  manage¬ 
ment.  DMS  and  RDBMS  are  emerging  technologies  that  can  be  used  in  the  near  future  for 
data  management.  In  the  long  run,  these  technologies  will  coexist  with  object  data  manage¬ 
ment  or  may  fully  integrate  with  object  data  management  systems  to  accomplish  data  man¬ 
agement  functions. 

USABILITY 

Once  the  bulk  distribution  has  been  delivered  to  the  CTODO,  another  set  of  management 
functions  needs  to  be  performed  to  deliver  the  TOs  to  maintenance  and  operations  users. 
These  functions  include: 

•  Loading  the  distribution  into  the  CTODO  database; 

•  Identifying  the  TOs  that  changed  since  the  last  distribution; 

•  Building  the  customized  distributions  for  Work  Areas  based  on  their  profiles; 

•  Delivering  the  TOs  in  the  requested  form  (via  LANs,  media,  or  printed  copies); 
and 

•  Keeping  track  of  ordering,  distribution,  and  feedback  (change  requests)  infor¬ 
mation. 

RDBMS  technology  is  central  to  supporting  these  management  functions. 

When  the  TOs  reach  their  ultimate  destination  (shops  and  flight  lines)  they  will  have  the  tags 
and  related  information  embedded  within  them  to  be  used  in  a  Type  B  or  Type  C  manner  by 
the  On-Line  Delivery'  System  (ODS).  Even  though  the  management  techniques  used  were 
Type  B,  the  end  result  at  the  destination  point  is  similar  to  Type  C. 

B2.2.4  Type  A  Management  Approach 

Even  with  the  most  optimistic  view  on  the  amount  of  existing  inventory  to  be  converted  to 
digital  form,  a  significant  number  of  Type  A  TOs  will  remain  and  have  to  be  managed  by  AF- 
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TOMS.  These  paper  TOs  will  exist  in  their  current  form  as  page  masters,  and  be  reposited  as 
they  are  today.  However,  the  information  that  identifies  and  tracks  these  TOs  will  be  entered 
in  the  cataloging  step  for  AFTOMS  (so  that  AFTOMS  can  manage  these  TOs). 

Management  of  Type  A  TOs  is  not  as  sophisticated  as  Type  B.  Printing  will  take  place  at  Tier 
2.  Distribution  will  be  in  paper  from  the  ALC  (Tier  2)  to  the  bases.  Change  management  will 
occur  similarly  to  today’s  environment,  except  that  the  AFT022  processing  will  be  auto¬ 
mated.  No  on-line  delivery  capability  will  exist. 

B2.2.5  Type  C  Management  Approach 

Type  C  data  (C-  or  C)  will  exist  in  the  AFTOMS  repository  in  database  form.  A  basic  differ¬ 
ence  between  Type  C-  and  C  is  the  dynamics  of  view  creation.  Type  C  data  allows  for  an 
unlimited  number  of  views  to  be  created  by  users  on  demand.  Type  C-  data  delivery  restricts 
the  set  of  predefined  views  to  the  same  set  as  Type  B-K  From  a  management  perspective. 
Type  C-  is  similar  to  Type  B  +  except  for  the  underlying  data  management  tools. 

Type  C  could  be  managed  within  the  AFTOMS  structure  given  the  additional  sophisticated 
functionality  in  authoring,  verification,  change  management,  and  on-line  delivery.  Also. 
Type  C  information  extends  beyond  the  technical  data  included  in  TOs.  There  can  be  linkages 
to  other  types  of  related  and  supporting  information  residing  in  other  databases  or  systems. 
This  information  is  merged  at  the  delivery  system  (e.g..  Integrated  Maintenance  Information 
System  (IMIS)). 

A  key  difference  in  the  management  of  Type  C  and  Type  C-  data  would  exist  in  the  distribu¬ 
tion  function.  To  allow  views  created  on  demand  and  by  merging  Type  C  data  with  other  data¬ 
bases,  AFTOMS  must  distribute  the  database  to  the  delivery  system.  With  Type  C-  require¬ 
ments  for  end  users,  AFTOMS  need  only  deliver  the  predefined  views. 

B2.2.6  Summary  of  TO  Management 

In  the  previous  section,  the  approach  to  management  of  a  heterogeneous  TO  suite  was  de¬ 
scribed  on  a  function-by-function  basis.  Key  points  of  this  integrated  approach  for  the 
FY91-FY93  system  implementation  are  summarized  below: 

•  Keep  the  authoring  process  as  it  exists  today; 

•  Eliminate  some  redundancy  in  the  TO  suite  during  the  cataloging  function  (i.e., 
graphics,  warnings,  tables,  etc.); 

•  Prevent  unauthorized  views  of  the  data; 

•  Incorporate  Type  C  concepts  within  AFTOMS  constraints; 

•  Reduce  Distribution  and  Change  Management  complexity; 

•  Deliver  TOs  in  a  form  that  can  be  used  like  Type  C  data; 

•  Identify'  at  least  one  of  the  new  weapon  system  programs  that  will  be  develop¬ 
ing  the  full  Type  C  capability,  and  whose  deployment  schedule  is  planned  for 
the  mid  1990s;  and 
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•  Plan  and  develop  a  parallel  management  capability  within  AFTOMS  for  this 
TO  suite,  thus  allowing  many  of  the  difficult  technical  and  interface  issues  to 
be  worked  out  in  a  time  frame  that  coincides  with  the  availability  of  the  full  set 
of  Type  C  technology  components. 

In  the  near  term,  the  end  users  will  acquire  most  of  the  desired  functionality  without  placing 
any  additional  burden  on  authors  or  managers  of  TOs. 

B2.2.7  Risk  Assessment 

For  management  of  the  Air  Force  digital  TO  inventory,  several  key  issues  affect  the  AFTOMS 
approach  to  acquiring  a  total  management  capability.  They  are: 

•  Percentage  of  the  inventory  of  Type  B  and  Type  C  TOs  in  the  FY95  timeframe; 

•  Availability  of  commercial  off-the-shelf  solutions  for  Type  B  and  Type  C  TOs 
in  the  FY95  timeframe; 

•  Similarities  and  differences  in  all  the  supporting  operational  techniques  of  the 
functions  that  are  part  of  the  management  of  TOs; 

•  Availability  of  conversion  technology'  solutions  for  Type  A  to  Type  B  or  Type  C 
data;  and 

•  Solidification  of  the  data  interchange  standards. 

Development  of  Type  B  solutions  for  the  management  of  TOs  (including  all  supporting  func¬ 
tions)  is  much  further  along  than  is  development  of  operational  Type  C  solutions.  Also,  the 
required  data  management  approaches  are  significantly  different  for  Types  B  and  C,  so  that 
they  will  not  converge  into  one,  all-encompassing  solution  in  the  near  term.  The  same  is  true 
in  the  conversion  technology  and  data  interchange  standards  areas.  Trying  to  develop  a  single 
management  strategy'  for  all  types  of  TOs  in  the  near  term  would  leave  the  Air  Force  with  a 
high  risk  option. 

B2.2.8  Risk  Abatement 

Perform  a  detailed  operational  evaluation  of  the  Type  C  concept  as  soon  as  possible  to  estab¬ 
lish  the  AFTOMS  support  requirements.  Recognizing  that  a  minimal  amount  (percentage 
wise)  of  Type  C  data  will  exist  before  FY2000,  AFTOMS  development  should  maximize  the 
realization  of  TO  automation  benefits  by  focusing  first  on  full  Type  B  family  management, 
followed  by  incorporation  of  Type  C  support  for  those  new  weapon  system  programs  that  will 
employ  the  full  Type  C  concept.  For  non-Type  C  weapon  systems,  Type  B  +  TOs  would  pro¬ 
vide  the  Tier  4  users  with  similar  TO  data  display,  navigation,  and  cross  referencing  benefits 
as  offered  by  Type  C-  TOs  (as  described  in  Section  B2.2.2). 
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B2.3  CONVERSION  OF  TECHNICAL  ORDERS 


This  section  describes  the  conversion  of  the  current  TO  inventory  existing  in  paper  form  to 
digital  form. 

B2.3.1  Scope  and  Relevance 

In  Section  B2.2,  the  functions  that  make  up  TO  management  (i.e.,  distribution,  change  man¬ 
agement,  etc.)  were  defined  in  a  manner  to  take  advantage  of  automated  techniques  and  tech¬ 
nologies  using  digital  data.  The  CALS  Initiative  states  that  all  new  programs  that  are  sched¬ 
uled  to  come  on-line  in  1990  and  beyond  are  required  to  deliver  their  TOs  in  digital  form  to 
the  Air  Force.  Thus,  the  proliferation  of  new  paper  TOs  (Type  A)  will  be  halted  once  this 
regulation  is  adhered  to.  Also,  as  some  of  the  aging  weapon  systems  are  retired,  paper  TOs 
will  be  removed  from  the  inventory.  Still,  the  fact  remains  that  the  majority  of  TOs  in  the 
1990s  will  still  be  Type  A  unless  they  can  be  converted  into  digital  form. 

The  real  payback  of  digital  TO  management  is  when  the  majority  of  the  inventory  exists  in 
digital  form  and  all  of  the  functions  that  are  embodied  in  AFTOMS  can  be  applied.  For  ex¬ 
ample,  no  on-line  delivery  capability  would  exist  for  paper  TOs.  By  converting  the  TOs  from 
Type  A  to  Type  B,  the  distribution  function  (including  demand  printing  at  base  level)  can  be 
totally  automated.  Also,  change  management  can  be  fully  automated  if  the  TOs  are  in  Type  B 
(excluding  Type  B-)  form.  Once  the  TOs  are  in  Type  B  form,  additional  tags  can  be  added 
during  the  cataloging  step  to  upgrade  these  TOs  to  Type  B  + .  Type  B  4-  TOs  offer  much  great¬ 
er  functionality  in  on-line  delivery  and  presentation  of  predefined  multiple  views.  The  bene¬ 
fits  of  AFTOMS  can  be  accelerated  in  proportion  to  the  amount  of  TO  inventory  that  gets 
converted  and  subsequently  enhanced  through  tagging  and  cataloging. 

B2.3.2  Conversion  Approach 

TO  management  will  be  performed  on  a  weapon  system  basis.  Each  program  requires  a  uni¬ 
form  management  approach.  Fragmentation  of  the  TO  suite  (by  mixing  paper  and  digital 
types)  will  complicate  the  management  process,  especially  in  the  distribution  and  change 
management  functions.  However,  AFTOMS  can  support  heterogeneous  TO  data.  To  maxi¬ 
mize  benefits,  a  primary  goal  for  a  weapon  system  would  be  to  convert  the  entire  TO  suite. 
Although  isolated  conversion  of  individual  TOs  in  a  suite  will  solve  specific  management 
problems,  it  will  also  create  problems. 

Specific  issues  concerning  the  conversion  process  are  critical  to  its  success:  who  should  per¬ 
form  the  conversion;  what  technical  support  resources  are  required;  and  the  time  frame  to 
accomplish  the  task.  There  are  3  basic  options  for  performing  the  conversion: 

•  Senice  Bureau  -  The  task  can  be  contracted  out  to  conversion  service  bureaus 
having  the  automated  hardware  and  software  components  and  the  expertise  in 
this  area.  They  usually  charge  on  a  per-page  basis  depending  on  the  number 
and  complexity  of  the  TO  pages; 
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•  Contractor  -  If  the  weapon  system  program  has  not  yet  reached  PMRT,  the  re¬ 
sponsibility  for  conversion  can  be  assigned  to  the  prime  contractor  (along  with 
the  appropriate  funding);  and 

•  Organic  Conversion  Center(s)  -  The  Air  Force  could  institute  one  or  more  con¬ 
version  centers  (perhaps  at  selected  ALCs)  to  convert  suites  of  TOs. 

Based  on  the  non-recurring,  one-time  need  for  conversion,  the  fast  pace  of  this  technology, 
and  the  intricacies  of  the  conversion  process,  the  most  beneficial  option  for  the  Air  Force 
would  be  the  Service  Bureau  approach. 

Regardless  of  the  option  chosen.  Air  Force  technical  data  specialists  will  be  needed  to  assist 
conversion  personnel  in  the  conversion  process.  Many  inconsistencies  and  irregularities  exist 
in  any  TO  suite,  especially  in  the  older  weapon  systems,  that  cannot  be  identified  and  cor¬ 
rected  by  total  automatic  conversion.  Specific  issues  will  arise  requiring  review'  and  decision 
making  by  TO  experts  (i.e.,  “Which  DTD  and  OS  should  the  TO  be  mapped  into?”  and 
“Should  one  merge  the  changes  in  the  supplements  into  the  TOs  they  augment?”).  It  is 
strongly  recommended  that  a  small  “tiger  team”  accompany  the  TOs  and  monitor  the  quality 
of  the  process. 

The  conversion  of  TOs  for  a  weapon  system  suite  should  take  place  in  a  short  chronological 
time  span.  Business  continues  as  usual  while  TO  masters  in  the  suite  are  collected  and 
brought  to  the  conversion  location.  During  this  conversion  period,  the  changes  must  be  care¬ 
fully  recorded  and  subsequently  added  to  their  digital  counterparts.  This  period  of  overlap 
must  be  minimized.  A  reasonable  goal  would  be  to  accomplish  the  conversion  of  a  weapon 
system's  suite  of  TOs  in  six  months. 

B2.5.3  Summary 

AFTOMS  is  a  system  that  will  apply  the  latest  automated  techniques  and  technologies  to  the 
management  of  TOs.  This  approach  is  geared  to  a  digital  repository  of  TOs.  Key  conversion 
points  are  summarized  below; 

•  Convert  as  much  of  the  inventory  as  soon  as  possible; 

•  Convert  on  a  weapon  system  basis  and  a  commodity  basis; 

•  Enhance  the  converted  TOs  to  Type  B+  form;  and 

•  Use  the  Service  Bureau  approach. 

B2.5.4  Risk  Assessment 

The  entire  area  of  document  conversion  is  in  a  rapid  state  of  development  and  change.  The 
solutions  that  are  available  today  and  in  the  next  couple  of  years  are  not  sufficient  to  handle 
the  large  bulk  conversion  requirements  of  the  Air  Force.  However,  by  the  time  AFTOMS  is 
fielded  in  FY93,  technology  advancements  will  significantly  reduce  the  cost  and  risk  of  this 
activity. 
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B2.3.5  Risk  Abatement 


AFTOMS  cannot  wait  until  FY93  to  begin  using  this  technology  for  document  conversion. 
Understanding  the  details  of  the  conversion  process,  the  characteristics  of  the  inventory,  the 
limitations  of  the  technologies,  etc.,  and  estimating  the  associated  costs  should  be  completed 
before  large  scale  conversion  efforts  begin.  Experimentation  should  begin  as  soon  as  possi¬ 
ble  on  a  small  scale. 


B2.4  CLASSIFIED  TECHNICAL  ORDERS 

This  section  discusses  classified  or  restricted  TOs  and  their  management  in  AFTOMS. 
B2.4.1  Scope  and  Relevance 

AFTOMS  security  implies  that  technical  data/information  be  easily  accessible  to  the  users, 
but  that  certain  sensitive  information/data  have  limited  user  accessibility.  Security,  accessi¬ 
bility1,  or  integrity  are  interrelated  terms  that  imply  policies,  procedures,  and  mechanisms  to 
protect  the  Air  Force  sources  and  assets  from  governments  or  from  outside  sources  (contrac¬ 
tors,  and  friendly/unfriendly  governments).  In  the  context  of  AFTOMS,  security  refers  to  the 
protection  of  information  and  assets  in  order  to  prevent  exploitation  through  interception, 
unauthorized  access,  or  other  related  intelligence  threats.  Accessibility  refers  to  the  non-dis¬ 
closure  of  information  to  those  without  a  need-to-know.  Integrity  refers  to  the  assurance 
that  the  information  has  not  been  altered  by  unauthorized  individuals.  All  three  are  applica¬ 
ble  to  AFTOMS  and  must  be  considered  within  the  overall  system  architecture. 

AFTOMS  security  policy  must  ensure  the  neutralization  and  mitigation  of  security  threats  by 
employing  cost-effective  security  procedures,  and  utilizing  secure  hardware,  software,  com¬ 
munications,  and  facilities  to  protect  the  system  and  the  information  resident  within  the  sys¬ 
tem.  Security  can  be  divided  into  three  distinct  elements: 

•  System  Resource  Security  -  Primarily  concerned  with  the  computer  systems  and 
the  information  maintained.  System  resources  include  firmware,  software,  and 
hardware  for  standalone  systems,  but  also  includes  network  system  compo¬ 
nents  such  as  transmission  signals  and  lines,  network/communication  software, 
and  various  components  of  communications  equipment  and  hardware.  Hard¬ 
ware,  software,  and  firmware,  whose  function  it  is  to  protect  system  resources, 
is  termed  a  Trusted  Computing  Base  (TCB).  A  typical  TCB  consists  of  an  oper¬ 
ating  system,  system  files,  and  data.  There  are  six  guidelines  to  evaluate  TCB 

r>  rtoi  »t*i  f-«  •• 
v,  Ui  i  tj  . 

o  Security  Policies — Access  rules; 
o  Document  Marking — Labels  and  categories; 
o  Identification ; 
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o  Accountability’ — Audit  information  for  who,  what,  and  when; 

o  Assurance — Ability  of  the  system  to  verily  the  above  four  guidelines; 
and 

o  Continuous  Protection — Guards  against  tampering,  unauthorized  modi¬ 

fication  of  data,  and  accidental  alternation/destruction. 

•  Security  Procedure  -  Concepts,  techniques  and  specific  measures  used  to  pro¬ 
tect  automated  systems  and  the  information  contained.  Security  procedures 
must  embody  the  various  regulations  and  directives  governing  physical,  admin¬ 
istrative.  and  technical  security. 

o  Physical  Security — Focuses  on  controlling  access  to  the  system; 

o  Personnel  Security — Controls  accessibility  clearance  of  personnel  using 

the  system; 

o  Administrative  Security — Establishes  standard  operating  procedures; 

o  Hardware  Security — Ensures  continuity  of  the  system; 

o  Software  Security — Secures  compliance  of  the  operating  system;  and 

o  Communication  Security — Protects  and  controls  all  information  trans¬ 
mitted. 

•  Security  Threats  -  Situations  or  conditions  that  could  affect  system  resources, 
specifically  the  information  contained.  Generally,  threats  can  be  grouped  into 
two  categories:  human  and  environmental.  Human  threats  can  be  intentional 
or  unintentional  while  environmental  ones  are  either  fabricated  or  natural. 

B2.4.1.1  Security  Policy  Within  DOD/Air  Force 

Computer  system  security'  needs  to  be  viewed  within  the  overall  context  of  DoD  security' spe¬ 
cified  for  DoD  elements  and  contractors.  Overall  policy  is  specified  in  DoDR  5200.1  and 
5220.22  for  internal  and  external  users.  The  external  aspect  must  also  be  considered  since 
AFTOMS  data  will,  at  times,  be  shared  with  contractors  and  other  governments.  Three  secu¬ 
rity  issues  associated  with  technical  data  in  a  shared  environment  arise: 

•  Data  classification  by  levels  and  categories; 

•  Data  aggregation  into  information  sets  that  on  the  whole  are  more  sensitive 
than  any  individual  element  by  itself;  and 

•  Contractor  data  proprietization. 

INFO  RMA  T ION  IDA  TA  CLA  SS1FICA  TION 

There  are  four  basic  information  classification  levels  within  DoD:  Unclassified.  Confidential. 
Secret,  and  Top  Secret.  These  levels  have  been  further  restricted  by  the  application  of  restric- 
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tive  labels  for  controlling  personnel  accessibility  based  on  a  need-to-know.  Access  authori¬ 
zation  is  granted  by  the  possessor  of  the  classified  information  in  accordance  with  AFR 
205-1.  Restrictive  labels  or  categories  can  also  be  applied  to  unclassified  information  which 
is  considered  to  be  sensitive  in  accordance  with  AFR  205-16.  Most  technical  manuals  are 
considered  to  be  sensitive.  Aggregating  unclassified  technical  data  presents  a  unique  prob¬ 
lem.  The  aggregated  data  may  require  a  higher  level  of  protection  than  the  individual  data. 
The  set  of  restrictive  labels  includes: 

•  RD  (Restricted  Data )  -  Information  defined  in  the  Atomic  Energy  Act  of  1954. 
Usually  this  label  is  associated  with  nuclear  weapons; 

•  CNWDI  (Critical  Nuclear  Weapon  Design  Information )  -  Nuclear  weapon  infor¬ 
mation  containing  critical  nuclear  weapon  design  information; 

•  FRD  (Formerly  Restricted  Data )  -  Usually  information  pertaining  to  nuclear 
weapons  that  is  no  longer  restricted  but  accessibility  must  be  still  controlled; 

•  WN INTEL  (Warning  Notice-Intelligence  Sources  of  Methods  Involved)  -  Infor¬ 
mation  that  contains  data  involving  intelligence  gathering/equipment; 

•  COMSEC  (Communication  Security)  -  Information  that  usually  involves  data 
involved  with  cryptological  equipment; 

•  NOFORN  (Not  Releasable  to  Foreign  Nationals)  -  Information  or  data  that  is 
not  releasable  to  foreign  nationals; 

•  PROPIN  (Proprietary  Information)  -  Contractor  or  government  information  or 
data  that  is  proprietary; 

•  NC  (Not  Releasable  To  Contractors)',  and 

•  EOD  (Explosive  Ordinance  Disposal). 

In  addition,  information  or  data  that  is  not  covered  by  the  above  special  labels,  and  whose 
accessibility  must  be  further  controlled  on  a  special  need-to-know  basis,  is  included  in  the 
Special  Access  Required  (SAR)  or  the  Sensitive  Compartmented  Information  (SCI)  Pro¬ 
grams,  in  accordance  with  DoDD  5100.55.  Within  the  above  classification  levels,  categories, 
and  programs,  accessibility  to  information  or  data  can  be  further  controlled  by  functions  to  be 
performed  on  the  information  (i.e.,  reading,  writing,  creation,  modification,  or  deletion  of 
data). 

SECURITY  DIRECTIVES 

DoD  has  published  documentation  to  assist  security  managers  in  determining  the  scope  of 
their  needs  and  the  criteria  for  developing  an  information  system  that  satisfies  those  require¬ 
ments.  The  documentation  is  sometimes  referred  to  as  the  rainbow  series  because  of  its  color. 
For  the  purpose  of  this  analysis,  the  yellow  book  (CSC-STD-003  and  004)  was  used,  which 
addresses  computer  security  requirements.  It  gives  the  method/formula  for  determining  indi- 
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viuual  clearance  against  data  sensitivity  to  develop  a  risk  index  and  determine  the  class  of 
TCB  needed  to  resolve  security  threats  (see  TABLE  B2-4).  The  orange  book  DoD 
5200.28-STD  was  used  to  determine  the  criteria  for  that  class  of  TCB.  A  TCB  is  a  system 
(hardware,  software,  firmware,  and  communications)  that  has  been  certified  by  the  National 
Communications  Security  Committee  (NCSC)  for  some  level  of  functionally.  The  set  of  crite¬ 
ria  contained  in  the  orange  book  defines  seven  classes  of  TCBs,  from  class  D  which  offers  no 
protection,  through  class  A1  which  verifies  system  design.  These  criteria  address  the  hard¬ 
ware,  software,  and  firmware,  but  do  not  address  applications  executed  on  a  TCB.  The  crite¬ 
ria  evaluate  four  main  areas:  Security  Policy,  Accountability,  Assurance,  and  Documentation. 
Each  class  builds  on  the  evaluation  criteria  in  the  previous  class. 

TABLE  B2-4.  TCB  COMPUTER  ENVIRONMENT  MATRIX 
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Trusted  Computer  Base  (TCB)  Classes 

•  Class  (D)  Minimal  Protection  -  Reserved  for  those  systems  that  have  been  eva¬ 
luated  but  fail  to  meet  the  requirements  for  a  higher  class; 


•  Class  (Cl)  Discretionary  Security  Protection  -  Nominally  satisfies  the  discre¬ 
tionary  security  requirements  by  providing  separation  of  users  and  data/infor¬ 
mation.  It  incorporates  some  of  the  controls  capable  of  enforcing  access  limi¬ 
tations  on  an  individual  basis.  This  class  is  for  cooperating  users  processing 
data  at  the  same  levels  of  sensitivity; 


•  Class  (C2)  Controlled  Access  Protection  -  This  class  enforces  a  more  finely 
tuned  discretionary  access  control  by  making  individual  users  accountable  for 
their  actions  through  the  utilization  of  login  procedures,  auditing,  and  resource 
isolation; 


•  Class  (Bl)  Label  Security  Protection  -  Requires  all  the  features  of  a  Class  (C2). 
In  addition,  an  informal  statement  of  the  security  policy  model,  data  labeling. 
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and  mandatory  access  control  over  named  subjects  and  objects  must  be  pres¬ 
ent; 

•  Class  ( B2 )  Structured  Protection  -  Includes  all  the  features  of  Class  (Bl).  In 
addition,  it  addresses  covert  channels.  The  TCB  must  be  carefully  structured 
into  protection-critical  and  non-critical  elements.  The  TCB  interface  is  well 
defined  and  can  be  subjected  to  more  testing  and  review.  Authentication 
mechanisms  are  strengthened,  trusted  facility  management  is  provided  for  ad¬ 
ministration  and  operator  functions,  and  stringent  configuration  management 
controls  are  imposed.  System  is  relatively  resistant  to  penetration; 

•  Class  (B3)  Security  Domains  -  In  addition  to  the  features  contained  in  Class 
(B2),  this  class  mediates  all  accesses  of  subjects  to  objects,  is  tamperproof,  and 
small  enough  to  be  subjected  to  analysis  and  tests.  The  system  is  highly  resis¬ 
tant  to  penetration;  and 

•  Class  (Al)  Verified  Design  -  System  in  Class  (Al)  is  functionally  equivalent  to 
those  in  Class  (B3)  in  that  no  additional  architecture  or  policy  has  been  added. 
The  major  difference  is  in  analysis,  which  is  derived  from  formal  design  specifi¬ 
cation  and  verification  techniques  and  the  resulting  assurance  that  the  TCB  is 
correctly  implemented. 

SECURITY  TERMS 

The  following  terms  are  considered  relevant  to  the  security  analysis: 

•  Least  Privilege  -  Requires  that  each  user  in  a  system  be  granted  the  most  restric¬ 
tive  set  of  privileges  needed  for  the  performance  of  authorized  tasks.  This  lim¬ 
its  the  amount  damage  that  can  result  from  accident,  error,  or  unauthorized 
use: 

•  Discretionary’ Access  -  Method  of  determining  and  limiting  who  has  w'hat  access 
(write  only,  read  only,  or  all  privileges)  to  the  information  or  data; 

•  Labeling  -  Ability  of  the  system  to  tag  all  information  and  users  with  labels  that 
describe  the  sensitivity  of  the  information  and  the  need-to-know  privileges  of 
the  users; 

•  Multilevel  Security -The  capability  to  simultaneously  process  multilevel  sensi¬ 
tive  data  by  users  with  different  need-to-know  requirements,  using  a  single  in¬ 
tegrated  system; 

•  Mandatory  Access  -  Ability  of  the  system  to  match  user  access  rights  with  the 
sensitivity  of  the  information,  and  deny  or  permit  access; 

•  Accountability  -  Ability  to  audit  system  unique  events  for  real  time  and/or  later 
analysis.  It  provides  a  record  of  who,  when,  how  long,  and  what  information 
was  accessed; 
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•  Assurance  -  Term  used  to  described  how  comfortable  the  Air  Force  is  with  the 
security  mechanisms  of  the  system; 

•  Integrity  -  Assurance  that  the  information  has  not  been  illegally  or  accidently 
modified  or  changed; 

•  System  High  -  A  mode  of  operation  in  which  the  system  hardware  and  software 
is  only  trusted  to  provide  need-to-know  protection  between  users.  All  system 
components  must  operate  commensurately  with  the  highest  classification/sen¬ 
sitivity  of  the  data.  Furthermore,  all  users  must  be  cleared  for  access  to  the 
highest  level  of  data  contained  in  the  system; 

•  Identification/Authentication  -  Requires  that  the  users  identify  themselves  with 
a  password  or  code  prior  to  gaining  access  to  the  system;  and 

•  Audit  -  Records  of  who,  what,  and  when  system  entrance  was  made  or  at¬ 
tempted. 

B2.4.1.2  Classified  Technical  Data 

Classified  technical  data  can  be  divided  into  data/information  that  is:  managed  by  Oklahoma 
City  Air  Logistics  Center/Technical  Order  System  Section-Central  Management  Office 
(OC-ALC/MMEDU)  through  the  LMTOS  system  and  distributed  by  the  responsible  ALC 
TO  manager;  or  technical  manuals  that  are  managed  and  controlled  by  individual  MAJ- 
COMS.  Separate  Operating  Agencies,  or  external  non-Air  Force  agencies. 

OC-ALC  MANAGED  TECHNICAL  DOCUMENTS 

OC-ALC  manages  209,500  Air  Force  technical  documents  through  the  LMTOS.  Less  than 
19c  of  the  documents  are  classified.  Classified  data  content  in  these  documents  ranges  from  a 
high  of  909c  to  a  low  of  10%.  As  more  technically  sophisticated  weapon  systems  are  devel¬ 
oped  and  acquired,  classified  data  will  increase  considerably.  Strategic  Air  Command  (SAC) 
estimates  that  40%  of  the  TOs  for  the  B2  aircraft  will  be  classified,  and  a  higher  percentage 
will  require  special  access.  The  B2  System  Program  Office  (SPO),  however,  estimates  that 
percentage  to  be  lower  (10-15%).  The  Advanced  Thctical  Fighter  (ATF)  SPO  estimates  that 
60-90%  cf  TOs  for  that  weapon  system  will  be  classified,  and  that  most  of  the  unclassified 
TOs  will  require  special  access  reflecting  the  increasing  complexity,  sophistication,  and  sensi¬ 
tivity  of  the  systems.  OC-ALC  manages  four  different  technical  document  programs:  Air 
Force  TOs,  Joint  Munitions  Effectiveness  Manuals  (JMEMs),  Computer  Program  Identifica¬ 
tion  Numbers  (CPINs),  and  Foreign  Military  Sales  (FMS)  technical  manuals.  Further  com¬ 
plicating  the  issue  of  classified  TOs  is  the  application  of  special  labels  or  categories  in  accor¬ 
dance  with  205-1  and  205-16.  Most  TOs  must  be  protected  as  sensitive  information.  The 
estimate  of  148,000  TOs  managed  by  LMTOS  does  not  include  the  200,000  inactive  TOs. 
The  number  of  classified  TOs  is  as  follows: 

•  Air  Force  -  148,000  TOs  (487  Confidential;  333  Secret;  and  1  Secret  Special 
Access  Required  (SAR)); 
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•  JMEMs  -  1,070  TOs  (604  Confidential:  and  134  Secret): 

•  CPINs  -  60,350  TOs  (695  Confidential;  and  582  Secret);  and 

•  FMS  -  Not  evaluated  since  they  are  managed  and  distributed  by  the  Security 
Assistance  Technical  Order  Distribution  System  (SATODS). 

MAJCOM  AND  SPECIAL  AGENCY  MANAGED  TECHNICAL  MANUALS 

TOs  in  this  category  are  created,  distributed,  reviewed,  and  managed  by  the  individual  M  AJ- 
COMs,  other  services,  agencies,  or  contractors.  They  comprise  specific  MAJCOM  supple¬ 
mental  data,  data  on  unique  command  systems  being  acquired,  systems  not  managed  by 
AFLC,  or  technical  data  for  systems  that  are  managed  by  other  agencies  (National  Aeronau¬ 
tics  and  Space  Administration  (NASA),  Department  of  Energy  (DOE),  DOT,  National  Secu¬ 
rity  Agency  (NSA),  etc.)  or  other  services.  The  impact  of  the  North  Atlantic  Treaty  Organiza¬ 
tion  (NATO)  and  mutual  defense  treaty  organizations  was  not  evaluated.  MAJCOM  and  spe¬ 
cial  agency  managed  technical  manuals  include  the  following: 

•  Special  Weapons-  2000  TOs  (100  Confidential;  and  200  Secret): 

•  Communication  Equipment'. 

o  Cryptologic  Aides  -  500  (35  Confidential;  10  Secret;  and  5  Top  Secret): 
and 

o  Maintenance  Bulletins  -  2700  (50  Confidential;  and  50  Secret). 

•  Joint  Explosive  Ordinance  Disposal  (EOD)  -  4000  TOs  (3600  are  classified): 
and 

•  Compartmented  Programs  -  Number  is  unknown  and  most  of  the  TOs  are  man¬ 
aged  by  the  contractor  with  very  limited  access  granted.  These  TOs  should  not 
be  included  within  AFTOMS. 

CLASSIFIED  MANUAL  CONTESTS. 

Classified  information  is  either  dispersed  within  the  basic  manual,  prepared  as  a  classified 
supplement  (containing  the  classified  paragraphs  or  data),  or  is  included  as  an  addition  to  the 
basic  unclassified  manual  and  includes  complete  system  functionality'  for  the  classified  and 
unclassified  data  needed  to  accomplish  the  maintenance  or  operations  tasks.  Requests  for 
technical  data  changes  of  non-AFLC  technical  data  is  governed  by  the  infrastructure. 

REQUISITION  AND  DISTRIBUTION  OF  CLASSIFIED  TECHNICAL  MANUALS 

Requisition  and  distribution  of  classified  TOs  is  handled  similarly  for  each  of  the  above  TO 
types  in  either  an  automated  or  a  manual  operation.  Requisition  is  accomplished  by  complet¬ 
ing  an  AFi  O  Form  43  which  certifies  that  a  need  exists  for  classified  TOs.  This  form  also 
depicts  the  signature  of  the  individual  who  is  authorized  to  request  these  TOs.  The  AFIO 
Form  187  is  used  to  order  the  required  manual  and  the  signature  is  compared  against  ihe 
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AFTO  Form  43.  However,  in  most  instances  the  AFTO  Form  187  is  electronically  trans¬ 
mitted  which  negates  the  value  of  depicting  the  signatures  on  the  AFTO  Form  43.  Both  the 
AFTO  Forms  43  and  187  are  unclassified.  Classified  TOs  and  changes  are  distributed  by  cer¬ 
tified/registered  mail  or  by  pouch,  depending  upon  sensitivity  level  and  delivery  location. 

CHANGE  REQUESTS 

Technical  manual  change  requests  are  accomplished  using  an  AFTO  Form  22  or  27  in  the 
same  manner  as  unclassified  change  requests,  except  when  they  contain  classified  data.  In 
these  instances  they  must  be  afforded  the  protection  needed  for  the  sensitivity-  level  of  the 
data. 

MASTER  LIBRARY 

At  the  user  level,  classified  TOs  are  not  stored  in  the  master  organizational  library.  They  are 
stored  and  maintained  by  the  individual  shops/users  in  classified  storage  containers  or  in  a 
secure  room/facility.  The  TOMA  handles  classified  data  in  a  similar  way;  the  specific  users' 
managers  store  and  maintain  these  documents  in  secure  locations. 

B2.4.1.3  AFTOMS  Security  Options  Evaluated 

The  following  security  concepts  were  reviewed  and  will  be  described  later  in  the  section: 

•  Option  One:  Multilevel  Security  at  all  Levels; 

•  Option  Two:  Multilevel  Security  at  the  TOMA  and  CTODO  Levels; 

•  Option  Three:  Multilevel  Security  at  the  CTODO  Level  Only;  and 

•  Option  Four:  Isolation  of  Classified  Technical  Manuals. 

B2.4.2  State  of  the  Technology 

TRUSTED  COMPUTER  BASE  (TCB) 

There  is  considerable  activity  in  the  TCB  environment  with  many  vendors  involved  in  certifi¬ 
cation  efforts  with  NCSC  and  the  National  Institute  of  Standards  and  Technology  (NIST)  to 
offer  TCBs  that  provide  various  levels  of  protection. 

Many  companies  are  hard  at  work  developing  secure  systems  to  include  LANs'WANs.  soft¬ 
ware,  hardware,  firmware,  etc.  Some  have  been  developed  and  are  being  certified,  while  oth¬ 
ers  are  in  the  development  stage.  There  are  only  two  UNIX  certified  C2TCBs  currently  avail¬ 
able  and  no  UNIX-based  secure  certified  systems  meeting  (B1/B2/B3)  criteria.  Although 
vendors  have  developed  and  certified  B2TCBs  and  higher,  they  are  equipment  and  operatin 
system-specific,  and  therefore,  could  possibly  cause  problems  for  the  AFTOMS  SPO  durin 
the  procurement  process. 

EN(  R  YET  ION  CA  PA  B1LITIES 

There  are  many  encryption  products  and  algorithms  presently  available  that  can  be  used  ei¬ 
ther  internally  or  externally  to  a  system  to  provide  a  wide  array  of  security  services.  AFTOMS 
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would  require  a  Type  I  capability.  There  are  also  chip  sets  that  have  been  developed  for  the 
Commercial  COMSEC  program  and  endorsed  by  the  NS  A.  Encryption  products/devices  of¬ 
fer  the  following  services: 

•  Privacy  of  Information  -  Cannot  be  unscrambled  without  the  key  or  keys; 

•  Integrity  of  the  Information  -  Assures  that  the  information  can  not  be  changed; 
and 

•  Digital  Signatures  -  Technique  used  to  compute  a  checksum  of  the  information, 
encrypt  the  checksum,  and  attach  the  checksum  to  the  information.  This  allows 
the  information  to  remain  unscrambled  and  eliminates  the  concern  that  some¬ 
one  will  alter  the  contents. 

SUBSYSTEMS 

Subsystems  address  one  or  more  of  the  following  functions:  Discretionary'  Access  Control, 
Identification  and  Authentication,  Object  Reuse,  and  Audit.  Subsystems  include  such  devices 
as  smartcards,  access  control  software,  etc. 

When  users  logon  to  a  system,  they  identify’  themselves  as  proper/legitimate  users.  Smart 
cards  go  one  step  further.  The  user  will  be  asked  to  furnish  a  fixed  number  available  on  the 
card  and  a  random  number.  Like  a  password,  this  validates  the  user  as  a  legitimate  user  by  the 
number  on  his'her  card  and  a  number  of  the  user's  choice.  This  approach  will  allc  v  a  profile 
to  detail  all  the  access  rights  of  each  user. 

B2.4.3  Security  Considerations 

Computer  security  is  only  one  piece  of  the  final  solution  that  includes: 

•  User  authentication; 

•  User  limitation  (least  privilege); 

•  Use  of  labels  to  reflect  proper  sensitivity; 

•  Limitation  of  access  privileges  to  specific  terminals,  (i.e.,  removable  hard 
drives,  secure  locations,  etc.); 

•  Multiple  functions  on  same  terminals,  (i.e..  management,  change  and  review- 
functions. .etc.); 

•  Auditing  in  real  time  and  after  the  fact: 

•  Limitation  on  the  number  of  unsuccessful  logons; 

•  Encryption  of  data: 

•  Secure  facilities: 

•  Level  of  user  clearances  (personnel  screening  practices); 
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•  Physical  security  of  the  equipment; 

•  Use  of  Tempest  equipment; 

•  Communications  privacy/protection;  and 

•  Active  and  passive  security  systems  (i.e..  alarms,  guards,  locks,  cameras,  etc.). 

Currently  there  are  approximately  7000  classified  technical  documents  (confidential  and  se¬ 
cret).  This  evaluation  did  not  consider  Top  Secret  or  SCI  documents  since  they  were  few  in 
number  (less  than  50)  and  would  require  higher  security  TCBs.  Although  the  highest  classifi¬ 
cation  level  considered  was  Secret,  the  application  of  special  labels  and  a  minimum  user 
clearance  level  of  unclassified  (with  special  category  access)  requires  a  B2/B3  TCB  rating.  An 
additional  consideration  was  made  to  prime  users  (Base  and  Depot  level  maintenance)  and 
how  best  to  satisfy-  their  needs.  The  majority  of  the  classified  technical  documents  encompass 
the  maintenance  instructions  needed  to  maintain  Air  Force  weapon  systems:  these  user  func¬ 
tions  will  be  implemented  on  an  on-line  TO  presentation  system  using  optical  storage  disks. 
The  evaluation  for  each  option  includes  a  system  overview,  assumptions,  and  feasibility. 

B2.4.3.1  Option  One — Mutilevel  Security  at  all  AFTOMS  Tiers 

SYSTEM  DESCRIPTION 

AFTOMS  is  B2  B3  'I  ('Bat  all  tiers.  Therefore,  ail  tiers  can  store,  distribute,  review  and  man- 
ace  classified  TOs. 


SYSTEM  OVER\  IEW 


Option  1  permits  AFTOMS  to  create,  deploy,  and  manage  TOs  throughout  all  three  tiers  (see 
FIGURE  B2-2).  Classified  multi-category  documents  would  be  stored,  changed,  and  man¬ 
aged  within  a  single  system.  It  would  require  that  the  entire  system  be  rated  B2/B3  to  be  able 
to  store  and  distribute  classified  technical  documents  which  comprise  less  than  1G  of  total 
documents  managed  by  I.MTOS. 

ASSUMPTIONS: 

•  Classified  and  unclassified  TOs  would  be  stored  in  the  same  database; 

•  AFTOMA  would  store  a  back-up  master  digitized  TO  file; 

•  AGIO  Form  22  change  requests  including  classified  ones  would  be  transmitted 
electronically  via  FAN  and  or  Defense  Data  Network  (DDN); 

•  Personnel  aligned  to  AFTOMA.  TOMAs.  and  CTODOs  would  possess  at 
least  a  Secret  clearance;  and 

•  All  traffic  would  flow  through  the  AFFOMA. 


h;:i 


OTHER 


FIGURE  B2-2.  OPTION  1 — MULTILEVEL  SECURITY  AT  ALL  AFTOMS  TIERS 

FEASIBILITY 


Although  Option  1  meets  some  of  MAJCOM's  desires,  it  is  not  practical,  feasible,  or  cost 
effective  at  this  time.  A  (B2/B?)  TCB  that  operates  on  the  UNIX  operating  system  is  not 
presently  available.  In  addition,  since  the  primary  users  in  Tier  4  are  maintenance  techni¬ 
cians.  on-line  availability  of  TOs  should  not  be  required.  The  maintenance  users' presenta¬ 
tion  system  as  presently  planned  will  require  loading  the  TOs  via  a  recorded  media  (i.e..  opti¬ 
cal  disk,  removable  magnetic  hard  disk,  or  magnetic  tape). 

B2.4.3.2  Option  Two — Multilevel  Security  at  TOMA  and  CTODO  Levels 

SYSTEM  DESCRIPTION 

AFTOMS  is  C2  TCB  at  the  AFTOM  A  B2/B?  TCB  at  the  TOMA  and  CTODO  levels.  This 
would  allow  a  mixture  of  classified  and  unclassified  digitized  TOs  at  Tier  2  and  3.  and  would 
permit  users  to  directly  interface  on-line  with  the  CTODO.  The  management  function  for  all 
TOs  would  be  performed  at  all  tiers  in  an  unclassified  mode. 

SYSTEM  OVERVIEW: 

Option  2  allows  on-line  access  to  both  classified  and  unclassified  TOs  at  the  TOMA  and 
C  I  ODO  (see  FIGURE  B2-3).  Repositing  of  classified  and  unclassified  multi-category  TOs 
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within  a  single  system  would  be  accomplished  at  the  TOMAs.  The  AFTOM A  would  retain  all 
profiling  and  indexing  functions  and  also  give  Tier  4  users  on-line  access  to  technical  data 
from  the  CTODO  using  secure  LANs.  Implementation  of  this  option  would  require  the  AF- 
TOMA  to  be  C2,  and  the  TOMAs  and  CTODOs  to  be  B2/B3. 


FIGURE  B2-9.  OPTION  2— MULTILEVEL  SECURITY  AT  TOMA 

AND  CTODO  LEVELS 


ASSUMPTIONS: 

•  Classified  and  unclassified  TOs  would  be  stored  in  the  same  database; 

•  AFTO  Form  22  and  27  change  requests  including  classified  ones  would  be 
transmitted  electronically  via  LAN  and/or  DDN  to  the  TOMA; 

•  Personnel  with  access  to  the  TOMAs  and  CTODOs  would  possess  a  Secret 
clearance; 

•  TOMAs  and  CTODOs  would  manage  their  own  addressing  and  distribution  of 
traffic; 

•  TOM  A  endurability  back-ups  would  be  maintained  by  all  or  specific  TOMAs; 

•  A  concept  for  CTODO  endurability  back-ups  would  be  developed  in  conjunc¬ 
tion  with  the  MAJCOM  user  presentation  system  group;  and 

•  AFTOMA  and  TOMA  databases  would  not  be  interconnected  electronically. 
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FEASIBILITY: 

Although  Option  2  meets  M  AJCOM’s  desires,  it  is  not  considered  to  be  practical,  feasible,  or 
cost  effective  at  this  time.  A  B2/B3  TCB  that  operates  on  the  UNIX  operating  system  is  not 
presently  available.  Since  the  users  in  Tier  4  are  primarily  maintenance  technicians,  on-line 
availability  of  technical  data  from  the  CTODO  should  not  be  required.  The  maintenance 
users’  presentation  system  would  require  loading  TOs  via  a  recorded  media  (i.e.,  optical  disk, 
removable  magnetic  hard  disk,  or  magnetic  tape). 

B2.4.3.3  Option  Three — Multilevel  Security  at  the  CTODO  Only 

SYSTEM  DESCRIPTION 

AFTOMS  is  (C2)  TCB  at  the  AFTOM A,  (C2)  TCB  at  the  TOMA,  and  (B2/B3)  TCB  at  the 
CTODO  level.  This  would  permit  classified  disks  to  be  mailed  to  the  CTODO  and  stored 
within  the  CTODO  computer  system.  Users  could  have  on-line  access  from  the  CTODO. 
The  management  function  would  remain  unclassified.  Individual  TOMAs,  TOCs  and  users 
would  have  secure  tempest  qualified  workstations  to  handle  classified  data. 

SYSTEM  OVERHEW: 

Option  3  allows  only  on-line  access  to  unclassified  technical  data  at  the  TOMA  (see 
FIGURE  B2-4).  TOMAs  with  classified  TOs  would  have  secure  workstations  with  remov¬ 
able  media  for  classified  storage.  This  allows  the  rating  of  the  TOMA  TCB  to  be  lowered  to 
C2.  The  CTODO  would  retain  B2/B3  rating  to  allow-  on-line  access  at  the  base. 

ASSUMPTIONS: 

•  The  TOMA  would  not  have  on-line  repositing  of  classified  TOs; 

•  Classified  change  requests  would  be  transported  by  other  means  than  LAN  or 
DDN  (i.e.,  via  registered  mail,  classified  electronic  mail); 

•  Personnel  at  CTODO  with  access  to  CTODO  data  bases  would  possess  a  secret 
clearance; 

•  Athough  secure  workstations  may  be  on  the  TOMA  LAN.  the  TOC  work  sta¬ 
tions  could  only  be  in  local  mode  when  processing  classified  TOs; 

•  MM_Rs  handling  classified  TOs  would  ship  classified  technical  data  via  re¬ 
corded  media  to  the  TOMA  publishing  center; 

•  Weapon  system  TO  suite  integrity  would  not  be  maintained; 

•  TOMA  endurability  back-ups  would  be  maintained  by  copies  of  classified  disk 
and  hard  drive; 

•  AFTOM  A  TOMA  and  CTODO  databases  would  not  be  interconnected  elec¬ 
tronically:  and 
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•  Delivery  of  classified  TOs  by  the  contractor  would  be  accomplished  by  disk, 
tape,  etc.,  through  applicable  TOMA  to  the  Work  Areas. 


FIGURE  B2-4.  OPTION  3— MULTILEVEL  SECURITY  AT  THE  CTODO  ONLY 
FEASIBILITY': 

Although  Option  3  meets  M  AJCOM’s  desires,  it  is  not  considered  to  be  practical,  feasible,  or 
cost  effective  at  this  time.  A  B2/B3  TCB  is  not  presently  available  that  operates  on  the  UNIX 
operating  system  for  the  CTODO.  Since  the  predominant  users  in  Tier  4  are  maintenance 
technicians,  on-line  availability  of  technical  data  from  the  CTODO  should  not  be  required. 
The  maintenance  users'  presentation  system  would  require  loading  of  TOs  via  a  recorded  me¬ 
dia  (i.e.  optical  disk,  removable  magnetic  hard  disk,  or  magnetic  tape). 

B2.4.3.4  Option  Four — AFTOMS  is  Not  Classified 

SYSTEM  DESCRIPTION 

AFTOMS  is  a  (C2)  TCB  at  all  levels.  This  would  allow  management  functions  to  be  per¬ 
formed  for  ali  TOs.  However,  classified  TOs  would  be  distributed  to  approved  users  and  con¬ 
tent  managers  only  on  paper  or  on  a  separate  classified  optical  disk  for  use  on  a  user  presenta- 
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tion  system;  and  classified  TOs  would  not  be  stored  within  AFTOMS.  This  would  require 
user  presentation  systems  to  be  graded  to  meet  the  appropriate  TCB  level.  Additionally,  a  C2 
TCB  would  be  capable  of  distributing  sensitive  unclassified  technical  data  in  accordance  with 
205-16. 

SYSTEM  OX^ERVJEW: 

Option  4  allows  on-line  access  of  unclassified  TOs  at  all  levels  (see  FIGURL  B2-5).  TOCs 
and  TOMAs  handling  classified  technical  data  would  use  secure  workstations.  This  lowers 
the  rating  of  all  TCB  levels  to  C2.  Classified  TOs  would  be  distributed  strictly  by  recorded 
media  throughout  the  AFTOMS  infrastructure. 


ASSUMPTIONS: 

•  The  TOMA  would  not  have  on-line  repositing  of  classified  TOs; 

•  Classified  change  requests  would  be  transported  by  other  means  than  via  LAN 
or  DDN  (i.e.  registered  mail,  classified  electronic  mail); 

•  The  CTODO  would  distribute  classified  TOs  on  recorded  media  directly  to  the 
applicable  work  centers; 

•  Although  secure  workstations  could  be  on  the  TOMA  LAN,  they  could  only  be 
in  local  mode  when  processing  classified  TOs; 

•  A  concept  for  CTODO  endurability  back-ups  w'ould  be  developed  in  conjunc¬ 
tion  with  the  MAJCOM  user  presentation  system  group; 
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•  TOCs  and  TOMAs  handling  classified  TOs  would  ship  classified  technical  data 
via  recorded  media  to  the  TOMA  publishing  center;  and 

•  The  TOMA  database  and  the  TEMPEST  workstations  would  not  be  intercon¬ 
nected  electronically. 

FEASIBILITY: 

Option  4  is  the  most  practical  and  cost  effective  approach  for  handling  classified  TOs.  Some 
functionality  is  lost  in  removing  on-line  capability  for  classified  technical  data,  primarily  in 
handling  AFTO  Forms  22  an^  27  and  maintaining  TO  suite  integrity.  End-user  presentation 
systems  would  be  able  to  integrate  information  from  classified  and  unclassified  media. 

B2.4.4  Recommended  Approach 

It  is  recommended  that  Option  4  be  accepted  for  AFTOMS  development.  This  option  speci¬ 
fies  that  on-line  access  to  TOs  from  the  TOMA  and/or  CTODO  databases  be  relegated  only 
to  unclassified  data,  and  allow  for  all  TOs  to  be  listed  in  the  master  database.  This  option 
meets  the  requirement  of  AFR  205-16  for  sensitive  data.  The  recommendation  is  based  upon 
the  following  factors: 

•  Less  than  1 9c  of  more  than  200,000  technical  documents  managed  by  LMTOS 
(i.e.,  TOs,  JMEMs  and  CPINs)  and  used  within  the  Air  Force  are  classified; 

•  TCB  technology  has  not  yet  reached  a  point  where  off-the-shelf  security  sys¬ 
tems  and  software  certified  at  the  B1  TCB  and  above  levels  are  readily  avail¬ 
able.  The  small  number  of  UNIX-based  security  operating  systems  may  se¬ 
verely  impede  the  competitive  procurement  process.  A  contractor-developed 
security  package  (B2/B3  TCB  or  above)  would  require  NCSC  certification,  a 
process  that  could  take  years.  It  is  also  possible  that  the  prime  contractor 
would  not  be  able  to  achieve  certification  before  AFTOMS  Initial  Operational 
Capability  (IOC); 

•  The  cost  of  a  multilevel  B2  or  above  system  will  be  much  greater  than  a  C2 
controlled  access  with  TEMPEST  w-orkstations.  This  higher  cost  is  attributed 
to  the  cost  for  software,  encryption  devices,  physical  security,  secure  databases 
and  hardware,  etc.; 

•  System  upgrade  to  a  multilevel  mode  could  be  accomplished  when  TCB  tech¬ 
nology  matures  and  becomes  cost  effective  for  small  quantities  of  classified 
data.  This  position  should  be  re-evaluated  if  a  significant  increase  in  classified 
TOs  is  realized  with  the  introduction  of  the  B2  and  ATF  aircraft.  At  this  time 
the  B2  and  ATF  SPOs  are  forecasting  10-15%  and  50-70%,  respectively.  The 
ATF  percentage  appears  to  be  very  high;  however,  comparison  of  the  B2  dur¬ 
ing  the  same  stage  of  its  development  reflects  similar  percentages;  they  were 
later  reduced  drastically, 
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•  The  TCB  concept  will  be  retained  for  unclassified  TOs  to  preclude  technology 
transfer  and  protection  of  proprietary  and  sensitive  data.  An  audit  trail  (both  in 
real  time  and  after  the  fact)  would  be  available  to  permit  the  following  mecha¬ 
nisms  to  be  incorporated:  identification  and  authentication,  prevention  of  ob¬ 
jects  being  introduced  into  user  address  space,  deletion  of  data,  and  audit  trail. 
Implementation  of  a  C2  TCB  would  afford  greater  protection  of  technical  data 
than  is  presently  available; 

•  It  would  permit  the  use  of  security  sub-systems  that  have  such  additional  pro¬ 
tections  as:  discretionary  access  control,  prevention  of  object  reuse,  protection 
from  external  interference  or  tampering,  system  integrity’,  and  user  identifica¬ 
tion; 

•  Classified  TOs  will  be  managed  by  AFTOMS  using  either  no  titles  or  unclassi¬ 
fied  titles;  and 

•  Implementation  of  a  TCB.  regardless  of  class,  does  not  completely  resolve  the 
technical  data  aggregation  problem.  Implementation  of  access  control,  user 
authentication  codes,  audit  programs,  continuation  of  present  AFLC  TO  dis¬ 
tribution  and  requisition  codes,  and  the  use  of  automated  profile  registration, 
will  provide  greater  protection  for  unclassified  sensitive  technical  data  than  is 
presently  provided.  This  approach  meets  the  objectives  contained  in  AFR 
205-16. 

B2.6.5  Risk  Assessment 

The  area  of  secure  systems  is  extremely  complex  since  many  factors,  issues,  constraints,  etc., 
contribute  towards  an  acceptable  solution  for  the  situation.  After  much  evaluation,  the  AF¬ 
TOMS  SPO  produced  four  options,  each  with  varying  degrees  of  security  mechanisms.  Dur¬ 
ing  the  detailed  assessment  of  each  option,  many  risk  factors  surfaced.  Options  1,  2,  and  3 
each  had  a  very  high  level  of  risk  due  to  some  of  the  following  issues: 

•  Secure  systems  are  costly  to  develop  and  operate; 

•  The  technology  is  not  mature,  standardized,  and  approved  in  UNIX  environ¬ 
ments;  and 

•  Access  checking  and  user  interfaces  for  such  systems  are  very  complex. 

Given  the  above  issues  and  the  fact  that  approximately  3000  TOs  presently  managed  by 
LMTOS  are  classified,  it  seemed  appropriate  to  select  Option  4,  which  has  much  less  risk 
than  Options  1,  2,  or  3. 

B2.6.6  Risk  Abatement 

Option  4  does  have  a  significant  amount  of  added  risk  over  a  system  that  supplies  no  capabili¬ 
ty  for  handling  classified  TOs.  To  keep  this  risk  to  a  minimum,  it  is  essential  to  finalize  the 
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selection  of  this  security  approach  within  AFTOMS  as  soon  as  possible.  Once  this  decision  is 
reached,  al!  subsequent  functional  requirements  and  system  design  activity  must  be  worked 
on  to  account  for  this  level  of  security.  Security  features  are  an  integral  part  of  the  system,  not 
an  afterthought,  and  must  be  built  into  the  system  from  the  beginning. 
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SECTION  B3: 

Support  of  Heterogeneous  System  Users 


B3.1 


SCOPE  AND  RELEVANCE 


This  section  focuses  specifically  on  user  support  issues  related  to  AFTOMS  functionality.  The 
requirements  for  support  of  different  classes  of  users  within  AFTOMS  are  examined.  In  par¬ 
ticular,  various  user  interface  approaches  are  discussed  along  with  the  implications  of  Type 
B+  custom  delivery-  of  TOs  to  users.  Technologies  and  products  appropriate  to  this  area  of 
system  integration  are  explained  and  analyzed,  both  from  a  current  perspective  and  from  a 
projected  view  of  the  near  future. 

Design  of  an  appropriate  model  for  a  user  environment  in  AFTOMS  requires  examination  of 
the  system  as  a  whole  from  several  different  dimensions.  A  tabular  summary  of  relevant  di¬ 
mensions  is  presented  in  Section  2.3.  Aspects  of  some  of  these  dimensions  are  discussed  in 
greater  detail  below. 

The  first  issue  is  the  overall  characterization  of  the  nature  of  the  AFTOMS  system.  This  issue 
is  important  to  user  support  since  that  characterization  can  greatly  influence  the  resulting  user 
model.  For  example,  if  the  system  is  principally  defined  as  a  data  management  system,  then 
the  user  model  will  be  oriented  around  data  objects  and  data-oriented  manipulations.  If  the 
system  is  primarily  defined  as  a  text  or  document  management  system,  then  it  is  likely  that  the 
user  model  will  be  much  more  document-oriented.  If  the  system  is  viewed  as  largely  batch- 
oriented  rather  than  interactive,  then  that  will  affect  the  user  environment  by  structuring  its 
use  The  POC  work  indicates  that  AFTOMS  should  be  characterized  as  primarily  an  inter¬ 
active  information  management  and  delivery  system,  wherein  the  information  takes  on  many 
forms,  the  most  important  of  which  is  the  TO  itself  (i.e.,  the  document).  In  particular,  this 
definition  is  extended  beyond  the  traditional  view  of  the  document  to  focus  on  the  relation¬ 
ships  among  parts  of  different  TOs  in  a  weapon  systems  suite  for  the  purposes  of: 

•  Control  of  changes  to  "like  contents"  in  different  documents;  and 

•  Delivery  of  complete  and  accurate  task  or  subject-specific  technical  informa¬ 
tion  that  can  transparently  traverse  document  boundaries. 

The  information  contained  within  AFTOMS  should  be  characterized  as  mostly  document¬ 
like,  but  the  access  to  that  information  should  not  be  constrained  by  document  boundaries, 
nor  by  traditional  document  processing  techniques.  It  is  important  to  keep  in  mind  that  Tier  4 
requirements  strongly  influence  both  the  data  model  requirements  within  the  management 
part  of  the  system  and  also  the  resulting  user  support  requirements  for  authoring,  editing, 
cataloging,  and  verifying  TOs. 

The  second  issue  focuses  on  AFTOMS  users.  Different  classes  of  users  will  coexist  in  AF¬ 
TOMS  and  will  need  to  be  supported  by  the  system.  These  user  classes  include  the  following: 
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•  Management  subtypes: 

o  Tier  1  AFTOMA  Administrator; 
o  Tier  2  TOMA  Technical  Order  Manager; 
c  Tier  2  Distribution  Suite  Manager; 
o  Tier  3  CTODO  Manager,  and 
o  Tier  4  Work  Area  Designated  Manager. 

•  Data  Technician 'Specialist  subtypes: 

o  Tier  2  Publications  Technician, 
o  Tier  2  Production  Technician;  and 
o  Tier  3  CTODO  Distribution  Technician. 

•  Work  Area  User  subtypes: 

o  Tier  4  Maintenance  Technicians  (depot,  in-shop,  and  on-aircraft). 

The  goal  of  AFTOMS  is  to  make  all  AFTOMS  users  more  productive.  Thu's  goal  is  dependent 
on  the  design  and  the  quality  of  AFTOMS  implementation  and  integration.  AFTOMS  can 
either  enhance  or  reduce  this  productivity. 

For  AFTOMS  the  key  aspects  of  support  for  a  heterogeneous  user  base  include  the  following: 

•  Enhanced  availability  and  usefulness  of  technical  information: 

o  TypeB+  tagging  of  TO  information  to  present  only  task  relevant  data, 
facilitate  navigation,  and  link  related  data; 

o  Use  of  abstracts,  cross-referencing,  and  other  indexing  to  support  more 
efficient  searches  and  interoperability,  and 

o  Linkage  of  related  sections  across  TOs  to  support  more  accurate  change 
management  across  the  TO  suite. 

•  Enhanced  availability  and  usefulness  of  management  information: 

o  Flexibility  in  presentation  of  management  data  for  report  schedule  gen¬ 
eration  in  both  textual  and  graphical  form;  and 

o  Richness  of  access  paths  to  management  information  along  the  lines  of 
typical  database  queries. 

•  Data  access  control: 

o  Allow  need-to-know  access  for  all  user  classes; 
o  Enable  use  of  predefined  technical  information  ’’views”  at  Tier  4;  and 
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o  Use  work  area  and  base  CTODO  profiles  for  automatic  distribution  of 
technical  information  targeted  to  individual  or  organization’s  needs. 

•  Intelligent  but  simplified  user  environments,  despite  the  complications  result¬ 
ing  from  concurrent  handling  of  heterogeneous  data  and  reliance  on  heteroge¬ 
neous  hardware  and  software  platforms: 

o  Focused  tasks  for  easier  learning,  lower  training  costs,  faster  processing, 
fewer  steps  and  checks,  fewer  errors,  and  less  rework; 

o  Reduced  environmental  complexity  and  clutter  to  promote  understand¬ 
ing  through  use  of  predefined  selection  options,  Air  Force  terminology, 
small  choice  sets,  intuitive  branching  during  selection,  etc.; 

o  Consistency  of  the  interface  within  a  user  class  (at  least)  and  consistency 
between  displayed  and  printed  information; 

o  Emphasis  on  interactive  modes  rather  than  batch; 

o  Implementation  of  interactive  interfaces  and  use  of  modem,  intuitive, 
direct-manipulation  graphical  user  interfaces  (GUIs)  rather  than  tradi¬ 
tional  character-oriented  interfaces;  and 

o  Tradeoff  performance  where  necessary  to  gain  user  friendliness  and 
data  accessibility. 

«  Data  access  transparency: 

o  Transparent  access  within  user  class  across  a  distributed  database  and 
heterogeneous  server  platforms;  and 

o  Transparent  access  within  user  class  (at  least)  from  heterogeneous 
workstations. 

•  Improved  work  flow: 

o  Use  of  tools  and  mechanisms  such  as  in-boxes,  work  queues,  project 
management  programs,  and  the  like  to  afford  managers  greater  control 
over  task  assignments  and  work  flow-,  and 

o  Streamlining  of  existing  manual  processes  into  more  efficient  auto¬ 
mated  processes. 

•  Interoperability  of  AFTOMS  with  other  systems  and  programs: 

o  Requirements  for  AFTOMS  to  interface  to  other  systems  may  imoose 
constraints  on  the  user  environment  at  Tiers  3  and  4;  and 

o  To  maximize  use  of  workstations,  AFTOMS  should  coexist  on  the  same 
workstation  with  other  programs  and  personal  productivity  tools  al- 
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ready  in  use  or  anticipated  to  be  used  in  the  future.  These  tools  could 
include  electronic  mail,  spreadsheets,  wordprocessors,  and  other  office 
automation  urograms. 

•  Data  accuracy  and  system  reliability: 

o  Overall  system  reliability  (reduced  downtime,  reliable  and  easy-to-use 
backup  and  archiving  techniques,  etc.)  enhances  user  confidence  in  the 
system  and  leads  to  greater  acceptance  and  maximized  use;  and 

o  Accurate,  up-to-date  technical  and  management  data  also  increases 
user  confidence  in  the  system  and  improves  overall  productivity. 

The  critical  aspects  for  AFTOMS  are  data  control  (accuracy  and  deliver)-  of  relevant  data) 
and  availability  of  the  necessary  data  to  get  each  task  done.  The  remaining  aspects  are  impor¬ 
tant  only  to  the  extent  that  they  enhance  system  acceptance  and  increase  user  productivity. 

The  available  technologies  and  standards  also  have  an  impact  on  the  quality  of  the  user  inter¬ 
face  in  that: 

•  Use  of  standards  can  provide  for  more  consistency,  but  can  also  lead  to  the 
’’least-common-denominator’’  effect; 

•  Lack  of  standards  can  increase  development  costs  and  make  it  difficult  to  pro¬ 
vide  a  consistent  user  interface,  and  modifications  and  upgrades  at  a  later  date; 
and 

•  Available  user  interface  technologies  will  affect  the  user  interface  design  by 
providing  both  possibilities  and  limitations  to  the  designers. 

B3.2  STATE  OF  INTEGRATION  FEASIBILITY 

In  the  subsections  below,  characterization  of  AFTOMS  from  a  user  perspective  is  discussed, 
classes  of  users  within  AFTOMS  are  defined,  some  key  aspects  of  user  support  are  elaborated 
upon,  and  selected  relevant  technologies  and  standards  are  introduced. 

B3.2.1  The  Nature  of  the  AFTOMS  System 

AFTOMS  is  a  large  system  covering  a  broad  range  of  functions.  Since  the  topic  of  user  sup¬ 
port  is  so  broad,  the  nature  of  the  AFTOMS  System  should  be  perceived  and  analyzed  as  a 
whole  system. 

The  concept  of  a  TO  management  system  in  the  Air  Force  can  be  perceived  in  many  ways. 
However,  AFTOMS  is  clearly  not  a  classic  Management  Information  System  (MIS),  nor  is  it 
an  On-Line  Transaction  Processing  (OLTP)  system.  Even  though  AFTOMS  does  generate 
transactions  and  manages  information,  MIS  and  OLTP  are  not  adequate  as  models  for  AF¬ 
TOMS.  The  three  primary  reasons  for  this  include: 
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•  Conventional  data  management  systems  are  not  designed  to  handle  large  doc¬ 
uments; 

•  Conventional  data  management  systems  are  not  designed  to  handle  text  and 
graphics;  and 

•  AFTOMS  is  primarily  concerned  with  maintaining,  altering,  managing,  cata¬ 
loging,  and  distributing  TOs,  which  are  essentially  very  large  technical  docu¬ 
ments. 

Conventional  data  management  systems  are  not  designed  to  incorporate  text  and  graphics. 
Instead  they  are  optimized  to  manage  small  structured  items  of  data,  principally  numbers  and 
short  text  strings.  OLTP  is  structured  to  manage  high-volume,  time-critical,  relatively  simple 
transactions  such  as  bant-  account  updates  or  other  financial  transactions.  The  management 
of  large  technical  documents,  as  opposed  to  data,  using  conventional  data  management  sys¬ 
tems  creates  some  very  difficult  problems.  The  typical  output  iorm  of  a  technical  document 
consists  of  a  fully-composed,  complex  manual  with  hundreds  of  pages,  table  of  contents,  in¬ 
dex.  etc.;  updates  require  specialized  text  and  graphical  editors  rather  than  form-based  pro¬ 
grams:  changes  are  made  overextended  time  periods.  These  are  just  a  few  of  the  many  differ¬ 
ences  between  managing  documents  and  managing  data. 

Large  corporations  and  government  agencies  have  long  wrestled  with  the  problem  of  manag¬ 
ing  high  volumes  of  large  documents  in  their  computer  systems.  Most  of  these  systems  have 
been  primarily  concerned  with  problems  in  output  or  publishing.  Various  corporations  and 
government  agencies  have  tackled  the  indexing  and  retrieval  problems  using  large  library 
management  systems.  Current  designers  of  document-oriented  systems  are  focusing  on  the 
use  of  new  technologies  to  help  handle  text  and  graphics  in  new  ways  that  allow  a  greater 
freedom  in  delivery  of  customized  "views”  of  textual  and  graphical  data.  There  is  a  strong 
movement  away  from  statically  composed  page  images  and  toward  a  dynamic  end-user  inter¬ 
active  environment.  As  was  mentioned  at  the  recent  "Expert  Communications  ’89”  confer¬ 
ence.  new  terms  for  this  style  of  environment  include  ’’hyperpublishing”  and  "knowledge  pub¬ 
lishing”.  Perhaps  a  better  term  is  "content-oriented  publishing”,  as  the  new  emphasis  is  on 
content  rather  than  on  form. 

New  trends  are  supported  by:  new  technological  advances  in  workstations,  memory’,  and 
printer  hardware;  new!  standards  such  as  SGML;  and  new  software  technologies  such  as  hy¬ 
pertext  and  object-oriented  programming.  Tfechniques  adopted  from  older  text  management 
systems  (such  as  electronic  publishing  systems  and  library  management  systems)  are  being 
combined  with  new  technologies  and  techniques.  Publishing  system  vendors  are  learning  how¬ 
to  handle  specific  issues  with  data  management  systems,  such  as  project  management  and 
work  flow.  Database  system  vendors  are  also  finding  ways  of  storing  text  and  graphics  in  their 
databases.  However,  those  disparate  models  have  not  yet  coalesced  as  an  integrated  unit  to 
be  used  as  a  single  model  for  the  entire  AFTOMS  system. 


A  general  model  representing  the  AFTOMS  system  must  be  defined  in  order  to  create  a  vi¬ 
able  and  consistent  user  model.  Selection  of  the  underlying  system  model  is  extremely  impor¬ 
tant  since  it  influences  not  only  the  user  view  but  also  the  fundamental  design  priorities.  For 
example,  if  AFTOMS  is  viewed  primarily  as  a  data  management  system  that  must  also  man¬ 
age  documents,  then  that  view  tends  to  favor  one  type  of  system;  conversely,  if  AFTOMS  is 
viewed  primarily  as  a  document  management  system  with  some  data  management  capability  , 
then  that  approach  favors  a  different  internal  system  design. 

The  POC  established  that  AFTOMS  should  be  characterized  primarily  as  a  high  volume,  doc¬ 
ument  management  system,  with  strong  controls  in  the  areas  of  work  flow  and  access  rights. 
However,  given  the  constraints  of  the  Air  Force  environment,  the  system  should  emphasize 
dynamic  and  tolerable  delivery  of  documents  to  the  end  user.  An  individual  user  should  have 
quick  and  easy  access  only  to  the  data  and  documents  (or  parts  of  documents)  that  are  task- 
oriented.  Every  user  should  have  readily  available,  the  data,  text,  and  graphic-handling  tools 
required  to  perform  their  job.  Both  public  and  private  data  entities  should  be  part  of  every 
user’s  functions.  The  data  ’’types”  that  the  user  can  manipulate,  and  the  access  paths  made 
available,  should  take  on  a  form  that  is  meaningful  in  the  environment  in  which  that  user 
works.  For  example,  fault  codes  would  provide  a  meaningful  access  to  TOs  for  a  mechanic, 
and  distribution  schedules  would  provide  meaningful  data  types  to  a  Tier  2  distribution  man¬ 
ager  at  a  data  center. 

In  summary,  the  user  view  of  AFTOMS  should  relate  as  directly  as  possible  to  the  user’s  mi¬ 
cro-environment,  maintaining  a  paradigm  for  those  items  that  have  meaning,  such  as  TOs 
and  Change  Requests;  however,  the  AFTOMS  environment  should  enhance  the  user's  pro¬ 
ductivity  by  providing  new  tools  and  techniques  for  accessing  those  familiar  items. 

B3.2.2  Class  of  Users  Within  AFTOMS 

This  section  takes  a  look  at  the  types  or  classes  of  users  the  AFTOMS  system  is  likely  to  serv  e. 
Within  the  classes  of  users,  many  current  user  job  functions  will  undoubtedly  change  when 
AFTOMS  comes  on-line,  a  situation  common  among  environments  where  automation  is  in¬ 
troduced.  For  example,  the  managing  of  warehouses  of  paper  storage  is  a  job  requiring  skills 
and  abilities  different  from  those  required  for  managing  electronic  document  distribution  on 
optical  disks. 

The  four-tier  AFTOMS  model  presumes  some  basic  user  type  classifications.  Three  distinct 
categories  of  users  emerge  from  implementation  of  the  AFTOMS  model: 

•  Class  i:  Manage^/administrator; 

•  Class  2:  Data  technician;  and 

•  Class  3:  Maintenance  technician. 

The  Class  1  manager/administrator  users  require  access  to  work  flow  control  tools  to  allow 
them  to  monitor  schedules,  do  planning  and  work  allocation,  etc.;  technicians  need  rapid  ac- 
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cess  to  the  data  relevant  to  their  particular  jobs,  such  as  portions  of  TOs,  change  recommen¬ 
dations,  schedules,  and  other  related  data.  Both  managers  and  technicians  need  access  to 
communications  facilities  and  other  general  utilities. 

It  is  apparent  that  the  set  of  functions  and  data  types  required  to  support  the  various  man¬ 
ager-users  of  AFTOMS  is  quite  similar  at  all  tiers,  although  the  actual  data  available  to  each 
type  of  manager  may  be  quite  different.  Job  functions  of  this  user  category  include  f  acking  of 
the  TO  change  process,  system  administrative  functions,  work  flow  and  project  management, 
and  the  managing  and  scheduling  of  TO  production  and  distribution. 

The  Class  2  data  technician  users  work  primarily  at  Tiers  2  and  3.  These  users  can  be  divided 
into  two  sub-categories: 

•  Distribution  technicians  at  Tiers  2  and  3  -  Tasks  focus  mainly  on  production, 
distribution,  and  data  center-relaied  system  administration  (data  manage¬ 
ment-oriented  tasks);  and 

•  Publications  technicians  at  Tier  2  -  Tasks  focus  mainly  on  altering  and  repub¬ 
lishing  TOs  (document-oriented  tasks). 

The  tools  that  the  distribution  technician  requires  to  perform  the  job  are  similar  to  (or  a  sub¬ 
set  of)  those  tools  that  the  AFTOMS  manager  needs,  namely  tools  for  facilitating  the  flow  of 
work,  scheduling,  distribution,  and  other  administrative  tasks.  In  contrast,  the  tools  needed 
by  the  publications  technician  are  very  different. 

At  the  TOMA  the  TOs  are  prepared  for  eventual  use  at  Tier  4  by  the  publications  technician. 
There  are  at  least  three  possible  type3  of  publications  technicians: 

•  Technicians  involved  in  publications  tasks  such  as  adding  or  correcting  tags, 
links,  style  changes,  etc.: 

•  Writers  or  editors  who  review  and  correct  for  reading  level  or  editorial  style; 
and 

•  Engineers  or  technicians  who  comprehend  TO  content  ramifications  and  alter 
the  content  of  TOs  to  reflect  the  authorized  change  completing  a  change  re¬ 
quest. 

To  alter  technical  content  of  TOs,  an  engineering  technician  often  requires  coordination  with 
the  contractor.  The  engineering  technician  could  effect  the  change  by  using  a  form  requesting 
the  chdr.c_,  and  submitting  it  to  a  separate  publications  department  staffed  by  publications 
technicians  of  the  other  ty  o  types.  This  process  is  to  thu,  employed  in  the  cmient 

paper-based  system  (AFT0252).  The  publications  people  would  then  implement  the  desig¬ 
nated  changes  to  each  affected  TO  and  perform  the  steps  required  to  generate  a  composed 
and  paginated  new  version  of  the  documents. 
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With  FY89  technology,  this  process  seems  cumbersome  and  unnecessary.  It  is  more  feasible 
and  efficient  for  the  engineering  technician  to  decide  on  changes  made  to  text,  implement  the 
changes  and  generate  a  newly  composed  and  paginated  TO.  Except  for  considerations  of 
readability  or  other  editing  factors,  this  would  imply  that  there  is  no  need  fo.  a  separate  job 
function  to  implement  a  change  (analogous  to  the  ’’word  processing”  or  ’’technical  publica¬ 
tion”  center  that  exists  in  many  corporations).  The  engineering  technician  could  make  the 
change?  as  well  as  publish  the  TO.  This  type  of  user  is  often  referred  to  as  a  ’’knowledge 
worker”.  Serving  knowledge  workers  requirements  is  a  major  focus  of ’’knowledge  publish¬ 
ing". 

The  Class  3  maintenance  technician  users  (at  Tier  4)  represent  a  very  different  situation. 
Whether  in  the  depot,  on  the  shop  floor,  or  on  the  aircraft,  the  main  job  of  the  Tier  4  mainte¬ 
nance  technician  as  it  relates  to  AFTOMS,  is  to  access  and  read  the  parts  of  TOs  that  are 
pertinent  to  their  job.  Computer  tools  must  be  optimized  for  fast  access  and  rapid  traversals 
across  documents  rather  than  for  editing,  publications,  or  administrative  considerations. 

The  Tier  4  user  interface  has  different  requirements  from  those  of  the  managers  or  techni¬ 
cians  of  other  tiers.  Since  the  AFTOMS  boundary  of  responsibility  ends  at  the  Tier  3  CTODO, 
the  user  interface  chosen  for  the  Tier  4  technician  is  not  a  direct  responsibility  of  AFTOMS. 
However,  since  the  TOs  must  be  prepared  and  verified  by  AFTOMS  at  Tier  2,  AFTOMS 
system  designers  must  be  concerned  with  the  requirements  for  Tier  4  TO  delivery.  That  is, 
TOs  must  be  delivered  by  AFTOMS  in  a  form  that  is  useful  to  the  Using  Commands.  Given 
the  recent  rapid  advances  in  such  delivery  system  technology,  this  has  non-trivial  conse¬ 
quences  for  the  Tier  2  preparation  stage  inside  AFTOMS.'  For  example,  if  the  Tier  4  user 
model  is  implemented  with  hypertext-style  links  for  navigation  through  TOs,  those  naviga¬ 
tion  paths  must  be  set  up  inside  the  TOs  at  Tier  2.  The  navigation  paths  must  also  be  verified 
within  the  AFTOMS  domain.  In  a  broad  sense,  the  requirements  of  Tier  4  drive  the  function¬ 
ality  required  at  Tier  2,  especially  for  the  publications  technicians  and  all  persons  involved  in 
the  actual  preparation  and  verification  of  the  contents  of  the  TOs. 

The  method  of  Change  Request  processing  at  Tier  4  could  also  impact  all  AFTOMS  tiers. 
Examples  of  issues  encountered  in  the  Change  Request  process  include: 

•  Would  the  maintenance  technician  at  Tier  4,  who  finds  an  error  in  a  TO,  fill  out 
an  electronic  version  of  an  AFT022  form  (to  initiate  the  change  process)  and 
transmit  it  to  the  appropriate  parties  for  approval;  once  coordinated  and  ap¬ 
proved,  would  the  change  finally  reach  the  engineering  technician  at  Tier  2  who 
would  make  the  TO  changes?  or 

•  Should  the  maintenance  technician  simply  annotate  the  TO  (electronically) 
and  directly  transmit  a  copy  of  the  relevant  pages  and  his  annotation  to  Tier  2 
for  review  and  controlled  implementation? 
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The  latter  approach  to  the  Change  Request  process  is  more  direct  and  has  Jess  chance  of  mis- 
communication,  but  is  a  radical  change  to  current  Air  Force  procedures.  This  approach 
would  include  implementation  of  an  appropriate  model  for  Change  Recommendations  such 
as  an  evolution  from  an  electronic  AFT022  form  and  approval  process  to  an  integrated,  in¬ 
teractive,  direct  communication  between  Tier  4  and  Tier  2  technicians.  This  approach  would 
include  automated  techniques  for  eliminating  data  duplicates.  M  AJCOM  and  other  approv¬ 
als  could  be  incorporated  into  the  process  either  before  or  after  the  change  was  actually 
made.  Past,  interactive  tools  in  the  hands  of  the  knowledge  worker  could  save  several  steps  in 
the  Change  Request  process  and  elapsed  time  could  be  eliminated. 

In  summary,  various  types  of  tools  are  required  by  different  classes  of  users  in  the  AFTOMS 
environment.  The  manager/administrator  at  any  tier  needs  good  data  management,  adminis¬ 
trative,  and  planning  tools,  as  does  the  distribution  technician;  the  Tier  2  publications  techni¬ 
cian  needs  good  interactive  TO  editing  and  publications  tools;  and  the  Tier  4  maintenance 
technician  needs  a  flexible-and-interactive  access  mechanism  to  TOs.  Many  process  issues 
such  as  those  revoking  around  change  approvals  and  change  management  have  a  direct  influ¬ 
ence  on  the  user  model  since  they  can  profoundly  affect  what  tasks  need  to  be  accomplished  in 
an  electronic  TO  environment.  Tier  4  TO  usage,  while  not  a  direct  concern  of  AFTOMS,  has 
nonetheless,  a  profound  indirect  effect  on  the  TO  preparation  and  verification  stages  within 
AFTOMS  Tier  2. 

B3.2.3  Key  Aspects  of  Integrated  User  Support 

The  key  to  the  support  of  heterogeneous  users  in  AFTOMS  is  incorporation  of  several  overall 
principles  and  specific  technical  aspects.  In  addition  to  adherence  to  general  standards  for 
good  user  interface  design  that  should  be  part  of  any  system,  AFTOMS  particularly  needs  to 
address  the  following  overall  requirements: 

•  Enhanced  availability  and  usefulness  of  technical  information  (B+  data): 

o  Enhancement  of  TOs  with  B  4-  tagging  to  supportthe  Tier  4  user,  specif¬ 
ically: 

-  The  addition  of  links  to  support  rapid  navigation  to  text  and  figure 
references,  to  sections  from  T&ble  of  Contents  entries,  and  through 
branching  paths; 

-  Provision  for  views  customized  to  the  profile  of  the  user  especially  in 
regard  to  security  classification,  skill  level  and  configuration  variant; 

-  Generation  of  custom  work  packs  for  specialized  tasks  such  as  isola¬ 
tion  of  a  particular  fault; 

-  Convenient  synchronized  viewing  of  related  textual  and  graphical 
material; 

-  Demand  printing  of  tasks  and  custom  work  packs; 
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-  Synchronization  of  screen  images  and  printed  pages;  and 

-  Identification  of  changed  sections  within  TOs  as  well  as  replaced  TOs 
in  a  distribution. 

o  Use  of  abstracts  for  easier  location  of  particular  TOs.  Use  of  cross-ref¬ 
erencing,  and  other  indexing  to  support  more  efficient  access  to  points 
interna!  to  the  document.  Such  methods  could  include  full  text  search, 
hypertext  links,  and/or  indexing  of  documents  at  the  section  and  task 
level;  and 

o  Linkage  of  related  material  across  documents  to  provide  for  more  accu¬ 
rate  change  management.  Such  material  may  be  related  either  tightly  or 
loosely,  bm  when  one  instance  changes,  the  other  should  be  checked  to 
see  if  a  corresponding  change  is  needed.  Identical  material  shared 
across  documents  such  as  Warnings,  Cautions,  and  Notes,  should  be 
handled  by  storage  of  that  data  once  in  a  central  location. 

•  Enhanced  availability  and  usefulness  of  management  information: 

o  Flexibility  in  presentation  of  management  data,  for  report  and  schedule 
generation,  in  both  textual  and  graphical  form;  and 

o  Richness  of  access  paths  to  management  information  along  the  lines  of 
typical  database  queries.  An  example  of  such  a  query  is  "Find  all  F-16 
TOs  with  outstanding  Change  Requests  on  the  Fuel  System.”  An  easy- 
to-use  interface  to  such  queries  is  an  important  requirement  in  the  user 
model. 

•  Data  access  control: 

o  Access  to  public  data  should  be  controlled  with  passwords  and  other  se¬ 
curity  measures  applied  where  appropriate.  Direct  access  should  be 
provided  only  to  data  relevant  to  the  particular  user.  Implementation  of 
customized  access  might  require  customization  of  menus  and  other  user 
interfacing  mechanisms; 

o  Use  of  only  predefined  ’’views"  at  Tier  4.  Although  the  Tier  4  user 
should  be  provided  with  tools  for  navigation  through  TOs,  the  user 
should  not  be  allowed  to  define  those  navigation  paths,  nor  to  alter 
them;  and 

o  Use  of  Work  Area  and  base  profiles  for  automatic  distribution  of  tech¬ 
nical  information  targeted  to  the  individual  or  organization's  needs.  A 
Work  Area  profile,  for  example,  would  specify  the  particular  weapon 
systems  assigned  to  that  Work  Area.  When  a  new  TO  distribution  is  sent 
to  Work  Areas,  a  particular  Work  Area  receives  only  those  TOs  whose 
systems  and  subsystems  match  those  in  its  profile. 
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•  Intelligent  but  simplified  user  environments  despite  the  complication ;  result¬ 
ing  from  concurrent  handling  of  heterogeneous  data  and  reliance  on  heteroge¬ 
neous  hardware  and  software  platforms,  including: 

o  An  imaginative  design  that  provides  an  environment  to  support  higher 
user  productivity  and  efficiency,  rather  than  blind  automation  of  exist¬ 
ing  manual  processes.  Such  an  environment  should  aim  at  streamlining 
some  processes,  possibly  eliminating  others,  and  reducing  manual  inter¬ 
vention  to  a  minimum; 

o  Use  of  a  similar  user  model  within  AFTOMS  proper  (Tiers  1,2.  and  3), 
across  different  user  types  and  within  one  class,  to  keep  development 
cost  low  and  allow  for  some  degree  of  job  interchangeability.  Different 
tools  may  need  to  be  available  for  different  user  classes; 

o  Simplification  of  the  user  interface  to  reduce  total  training  investment, 
and  account  for  varied  skill  levels  of  users.  Some  allowance  for  an  "ex¬ 
pert  mode”  might  be  helpful  to  enhance  efficiency  for  more  skilled  us¬ 
ers: 

o  Flexibility  in  user  interface  customization  for  individual  skill  levels  and 
personal  preferences,  without  sacrificing  overall  coherence,  consisten¬ 
cy7,  and  design  integrity", 

o  Reduced  environmental  complexity  and  clutter  to  promote  understand¬ 
ing  through  use  of  predefined  selection  options.  Air  Force  terminology7, 
small  choice  sets;  intuitive  branching  during  selection,  etc.; 

o  Consistency  between  displayed  and  printed  information.  Since  the  re¬ 
liance  on  printed  versions  of  TOs  will  continue  to  exist  for  some  time, 
and  the  same  technician  may  view  the  same  data  either  electronically 
and;or  on  paper,  it  is  important  to  maintain  some  kind  of  correspon¬ 
dence  between  the  two  output  forms.  Display  of  electronic  TO  data  at 
Tier  4,  using  page  images  with  embedded  links  and  customizations  (the 
B  +  model)  is  one  way  to  accomplish  this  goal; 

o  To  implement  interactive  interfaces,  use  of  modem,  intuitive,  direct- 
manipulation  graphical  user  interfaces  (GUIs)  rather  than  traditional 
character-oriented  interfaces;  and 

o  Emphasis  on  interactive  modes  rather  than  batch.  The  overall  thrust  of 
the  user  interface  should  be  interactive  and  user-friendly,  and  batch 
programs  should  be  used  by  the  AFTOMS  user  where  appropriate  to 
the  job  at  hand  (e.g.  for  certain  data  format  conversions). 

’’Interactive"  should  not  imply  an  overemphasis  on  manual  interven- 


B3-11 


tion,  however.  For  example,  authors  generally  prefer  interactive  What- 
You-See-ls-What-You-Get  (WYSIWYG)  text  editors  to  other  types 
since  they  are  intuitive  and  easy-to-use,  and  can  receive  immediate 
feedback  on  the  ’’look"  of  their  document.  WYSIWYG  text  editors  di¬ 
rectly  interact  with  the  software  to  produce  the  formatted  document. 
This  WYSIY/YG  advantage  translates  especially  well  to  technical  docu¬ 
mentation  such  as  TOs  because  of  the  importance  of  accurate  coordina¬ 
tion  of  related  text  and  figures,  and  will  become  increasingly  important 
as  B+  linking  is  added  to  TOs. 

However,  some  WYSIWYG  publishing  systems,  such  as  desktop  pub¬ 
lishing.  require  the  user  to  make  all  page  layout  decisions.  These  par¬ 
ticular  programs  do  not  have  the  capability  of  making  page  layout  deci¬ 
sions.  High-end  technical  electronic  publishing  systems,  on  the  othi.r 
hand,  perform  page  layout  decisions  automatically  for  the  user.  This 
does  not  make  these  programs  any  less  "interactive"  since  the  user  can 
override  program  decisions  at  any  time,  but  they  are  less  "manual"  and 
more  automated.  Electronic  publishing  programs  are  simply  more  pow¬ 
erful  than  their  desktop  equivalents.  "Interactive”  should  imply  mean¬ 
ingful  interaction  between  the  software  and  the  user  without  overbur¬ 
dening  the  user  with  manual  tasks  or  decisions. 

•  Data  access  transparency. 

o  Transparent  access  within  user  class  across  distributed  system  data  and 
across  heterogeneous  server  platforms.  Transparent  does  not  imply  in¬ 
stantaneous,  rather  that  the  process  required  to  access  data  at  a  remote 
site  should  be  substantially  the  same  as  that  required  to  access  local 
data;  and 

o  Transparent  access  within  user  class  (at  least)  from  heterogeneous 
workstations.  This  is  difficult  to  achieve  if  the  workstations  vary  in  fun¬ 
damental  capabilities,  such  as  the  presence  or  absence  of  a  windowing 
interface.  As  will  be  discussed  later  in  this  document,  windowing  stanAs 
discussed  above,  tdards  such  as  X-Windows  help  alleviate  this  problem. 

•  Improved  work  flow: 

o  Use  of  tools  and  mechanisms  such  as  in-boxes,  prioritized  work  queues, 
user-definable  states  of  work  progression,  project  management  pro¬ 
grams,  etc.,  to  afford  managers  greater  control  over  task  assignments 
and  work  flow;  and 
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O  Streamlining  of  existing  manual  processes  into  more  efficient  auto¬ 
mated  processes.  Using  new  technologies  to  implement  more  efficient 
processes  is  preferable  to  running  traditional  programs  faster. 

•  Interoperability  of  AFTOMS  with  other  systems  and  programs: 

o  Requirements  foi  AFTOMS  to  interface  to  existing  computer  systems 
may  impose  constraints  on  the  user  environment  at  Tiers  3  and  4.  Link¬ 
age  from  TO  data  to  data  in  other  systems  should  follow  a  similar  model 
as  linkage  among  TOs  (e.g..  some  embedded  TO  links  could  access 
parts  information  data  from  a  parts  database).  This  information  should 
be  presented  in  the  AFTOMS  environment  rather  than  switching  to  a 
different  paradigm,  if  possible.  Some  accommodation  to  existing  sys¬ 
tems  may  have  to  be  tolerated,  however;  and 

o  To  maximize  use  of  workstations.  AFTOMS  should  coexist  on  the  same 
workstation  with  other  p-ograms  and  personal  productivity  tools  al¬ 
ready  in  use  or  anticipated  to  be  used  in  the  future.  These  tools  could 
include  electronic  mail,  spreadsheets,  wordprocessors,  and  other  office 
automation  programs.  Implementation  of  this  environment  is  facili¬ 
tated  by  multitasking  operating  systems  and  windowing  environments. 

•  Data  accuracy  and  system  reliability. 

o  Overall  system  reliabih'ty  (reduced  downtime,  reliable  and  easy-to-use 
backup  and  archiving  techniques,  etc.)  enhances  user  confidence  in  the 
system  and  leads  to  greater  acceptance  and  maximized  use;  and 

o  Accurate,  up-to-date  technical  and  management  data  also  increase' 
user  confidence  in  the  system  and  improves  overall  productivity’. 

B3.2.4  Relevant  Technologies  and  Standards 

Available  technologies  and  standards  can  have  a  significant  impact  on  the  natcie  and  quality 
of  the  user  environment.  Use  of  standards  can  provide  for  more  consistency  as  well  as  lower 
development  cost,  but  can  also  lead  to  the  Teast-common-denominator”  effect.  For  exam¬ 
ple,  X-Windows  is  fast  emerging  as  the  industry  standard  windowing  system  and  with  good 
reason:  it  allows  different  workstations  running  different  vendor’:  operating  systems  to  ex¬ 
ecute  the  same  program  with  the  same  user  interface  over  a  network.  But  it  has  several  docu¬ 
mented  problems  and  deficiencies,  not  the  least  of  which  is  performance.  Another  problem 
with  standards  is  the  difficulty  of  achieving  interoperability.  For  example,  many  relational 
database  systems  (RDBMSs)  supply  an  interactive  query’  interface  called  ”query-by-form”; 
but  this  is  a  character-based  interface  which  does  not  take  advantage  of  state-of-the-art  user 
interface  environments  such  as  those  bused  on  X-Windows.  The  particular  problems  pointed 
out  here  will  be  remedied  well  befo.  e  AFTOMS  is  deployed;  they  are  mentioned  only  to  illus- 


trate  the  point  that  at  any  given  moment  in  time,  even  widely-accepted  standards  are  not  pan¬ 
aceas  and  may  not  operate  well  in  combination  with  one  another. 

Another  dimension  of  the  standards  issue  related  to  user  environments  is  the  current  lack  of  a 
specific  user  interface  standard.  This  problem  should  be  resolved  in  the  very  near  future 
based  on  recent  developments  in  this  area.  The  following  subsections  discuss  this  issue  in 
more  detail. 


One  standard  that  is  s  jr  *o  be  pan  of  AFTOMS  is  Standard  Generalized  Markup  Language 
(SGML)  since  it  is  an  important  part  of  the  MIL-STD  1840  specification.  There  are  user 
interface  implications  here,  too.  SGML  was  designed  in  the  1970s.  and  in  publishing  environ¬ 
ments  it  was  used  to  mark  up  text  with  structural  tags.  The  marked  up  text  was  then  processed 
through  several  batch  programs  such  as  parsers  which  validated  the  SGML  markup  and  com- 
position  pagination  programs  that  typeset  the  text  according  to  pre-defmed  style  specifica¬ 
tion'  for  each  SGML  tag.  These  processes  required  operators  highly  skilled  in  both  SGML 
and  typesetting  In  the  1980s  the  environment  of  electronic  publishing  went  through  a  signifi¬ 
cant  transformation.  Word  processing,  persona!  computers,  laser  primers,  and  desktop  pub¬ 
lishing  influenced  publishing  vendors  to  move  to  more  interactive  S) •stems  supporting  proper¬ 
ty  sheets,  j  opup  menus,  and  WYSIWYG  editing.  Style  and  formatting  became  more  inte¬ 
grated  with  text  and  graphical  editing.  It  is  now  the  task  of  the  publishing  system  vendors  to 
adapt  SGML  to  these  interactive  environments. 

In  terms  of  user  inter! .ce-related  technologies,  important  developing  trends  include  hyper¬ 
text  and  hypermedia,  on-line  help  and  information,  full-text  retrieval  systems,  voice,  video, 
animation,  new  graphical  database  interfaces,  and  optical  disk  technologies. 

Another  area  of  technology  that  profoundly  affects  TO  delivery  at  Tier  4,  but  only  indirectly 
affects  AFTOMS,  is  the  area  of  portable  and  laptop  computers.  This  area  is  developing  so 
rapidly  that  it  is  difficult  to  gauge  the  future  of  FY89  state-of-the-art  technology.  Although 
flat  panel  display  technology  is  developing  rapidly,  it  is  prudent  to  assume  that  less  screen 
area  will  be  available  for  on-equipment  maintenance  than  at  other  user  sites  within  AF- 
TO.MS;  thus,  the  Tier  4  user  interface  must  be  flexible  in  its  design  to  accomodate  smaller 
screens.  Environmental  consideration  will  dictate  the  use  of  simple  user  input  mechanisms, 
such  as  limited  keystroke  commands.  Hypertext  can  be  used  to  reduce  fundamental  opera¬ 
tions  of  an  environment  to  a  few  commands.  Implications  for  TO  delivery’  of  AFTOMS  in¬ 
clude  the  delivery  of  TO  data  in  a  way  that  can  be  retrieved  by  Tier  4  hypertext-based  systems. 

B3.3  FEASIBILITY  OF  INTEGRATED  USER  SUPPORT 

This  subsection  is  an  overview  of  the  various  issues,  problems,  risks,  tradeoffs,  and  feasibili¬ 
ties  involved  in  building  an  integrated  system  to  support  AFTOMS’  heterogeneous  user  base. 
The  focus  is  on  two  time  frames:  current  (Fi'89),  and  full-scale  development  (FY91-FY93). 
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B3.3.1  In  FY89 


In  this  time  frame,  several  areas  are  of  particular  interest  in  terms  of  the  feasibility  of  building 
integrated  user  support.  These  include  user  interface  developments,  industry  and  de  facto 
standards,  data  management  and  access  control,  work  flow  modeling,  and  B  +  enhancement. 

B3.3.1.1  User  Interface  Developments 

Recent  rapid  improvements  in  pi  ice/performance  of  personal  computers  and  workstations, 
including  better  screen  resolutions  and  inexpensive  memory,  have  provided  the  platform  for 
user  interface  software  to  advance  to  new  levels  of  functionality.  The  mouse-and-icon- 
based,  direct  manipulation  user  interface  (originally  developed  at  Xerox  Parc  on  the  Star  and 
commercialized  by  Apple  with  the  Macintosh)  has  now  come  into  its  own  on  more  standard 
platforms.  The  advent  of  X-Windows  has  greatly  aided  this  transition.  Almost  all  UNIX  ven¬ 
dors  as  well  as  many  vendors  supplying  other  operating  systems  such  as  Digital's  VMS,  are 
basing  their  user  interfaces  on  an  X-\Vindows  environment.  The  availability-  of  this  environ¬ 
ment  even  on  low-cost  X-terminals  is  influencing  vendors  to  build  their  new  software  prod¬ 
ucts  on  X-Windows-based  GUIs. 

But  X-Windows  provides  only  the  lowest  level  of  windowing  standard  w-hich  results  in  hard¬ 
ware  independence.  The  standards  issue  is  now  being  debated  at  the  higher  levels  of  the  inter¬ 
face:  that  is.  at  the  programming  language  interface,  and  at  the  direct  user  interface  level, 
known  as  the  "look-and-feel".  Digital's  XUI  toolkit  is  rapidly  gaining  momentum  as  the 
programming  interface  of  choice  and  has  been  adapted  by  the  Open  Software  Foundation 
(OSF)  as  Motif.  The  "look-and-feel"  battle  has  reduced  to  two  principal  players:  OSF’s  Mo¬ 
tif,  and  AT&T/Sun  Microsystems'  Open  Look.  In  fact,  these  two  interfaces  are  quite  similar 
from  a  user  perspective.  One  of  the  advantages  of  X-Windows  is  that  programs  written  for 
one  ’’look-and-feel"  environment  will  run  on  a  different  "look-and-feel”  environment.  The 
user  interface  standards  issue  should  resolve  itself  quite  soon,  and  even  if  both  "look-and- 
feel  environments  continue  to  persist,  a  system  could  be  built  using  either  one,  or  both  envi¬ 
ronments,  without  serious  negative  impact,  A  larger  issue  concerning  buildability  is  that  this 
windowing  style  of  interface  is  more  difficult  to  program  than  a  character-based  interface, 
and  software  development  groups  are  reporting  longer  times  initially  to  develop  and  market 
new  products.  Later  subsections  of  this  document  will  discuss  the  Demo  System  experiences 
with  development  of  a  user  interface  for  AFTOMS  based  on  XUI  and  X-Windows. 

B3.3.1.2  Industry  De  facto  Standards 

As  a  result  of  the  CALS  Initiative,  SGML  support  is  being  integrated  into  word  processing 
and  publishing  environments  as  a  de  facto  standard.  However,  vendors  are  finding  it  difficult 
to  make  the  transition  to  SGML  for  the  following  principal  reasons: 

•  SGML  is  complex; 

•  SGML  is  a  language  designed  for  batch  systems;  and 
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•  It  is  difficult  m  icii orit  an  external  SGML  model  to  an  existing 
interna!  product  model. 

Despite  these  problems,  SGML  is  slowly  being  integrated  into  publishing  products,  and  sev¬ 
eral  new  products  designed  explicitly  for  SGML  have  been  recently  introduced.  These  new 
products  cover  the  areas  of  authoring/ediring.  auto-tagging  or  "optical  structure  recogni¬ 
tion",  interactive  validation,  and  batch  parsing.  Since  the  current  SGML  situation  is  un¬ 
sealed.  it  is  difficult  to  acquire  and  integrate  a  suite  of  software  tools  to  automate  SGML- 
related  processes  within  AFTOMS. 

B3.3.1.3  Data  Management  and  Data  Access  Control 

In  terms  of  data  management  issues  within  AFTOMS,  current  available  relational  database 
technology  appears  to  handle  the  requirements  adequately.  Relational  databases  are  well- 
proven  in  the  areas  of  managing  high  volumes  of  data,  and  providing  users  with  flexible  access 
to  that  data.  In  terms  of  transparent  data  access,  RDBMSs  provide  location  transparency  to 
data  which  is  stored  at  different  physical  sites.  Most  vendors  supply  location  transparent,  read 
access;  updates  are  more  difficult  and  are  not  handled  as  well.  For  the  user  interface,  there 
are  performance  considerations  associated  with  the  use  of  location  transparency,  particularly 
across  a  wide  area  network  (WAN).  When  a  database  access  will  be  delayed  due  to  travel  over 
a  WAN,  the  user  needs  to  be  notified.  Other  mechanisms  to  distinguish  slower  access  paths 
from  faster  paths  should  also  be  employed  to  warn  the  user  ahead  of  time  that  certain  queries 
will  take  a  great  deal  longer  than  others. 

In  the  current  environment  of  GUIs,  databases  are  quite  lacking.  No  vendor  has  integrated 
all  of  their  end-user  tools  into  a  windowing  environment,  although  all  of  them  intend  to  do  so. 
This  transformation  is  not  a  matter  of  making  existing  tools  run  under  X-Windows,  or  of  sup¬ 
porting  mouse  input,  but  rather  it  extends  to  the  development  of  some  new  user  interface 
paradigms  in  order  to  make  the  most  out  of  the  GUI.  There  are  no  technical  problems  with 
interlacing  databases  to  GUIs. 

Selection  of  an  underlying  data  model  for  AFTOMS  is  difficult,  yet  it  has  important  implica¬ 
tions  for  the  user  environment.  Relational  databases  handle  data  well  just  as  document  man¬ 
agement/publishing  systems  handle  documents  well.  However,  each  system  cannot  ade¬ 
quately  handle  the  other’s  data.  Progress  is  being  made  in  integrating  the  two  types  of  envi¬ 
ronments;  however  available  options  are  limited.  In  order  to  extract  the  maximum  function¬ 
ality  from  existing  software  in  FY89,  systems  with  requirements  such  as  AFTOMS  must  use 
some  combination  of  relational  databases  and  document  management/publishing  systems. 
Document  management  systems  work  best  for  the  publication  technician  users;  RDBMS's 
work  best  for  the  manager  class  of  users;  and  Hypertext,  or  on-line  delivery  systems  work  best 
for  the  maintenance  technician  class  of  users.  Systems  that  integrate  ail  three  technologies 
may  become  available  in  time  for  AFTOMS  deployment.  The  POC  experience  in  building 
such  a  hybrid  system  is  summarized  in  Section  B3.4.1.  The  feature  w’hich  brings  this  hybrid 
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system  together  is  the  user  interface  built  on  a  standard  X-Windows  platform.  Retrieval  of 
TOs  stored  internally  as  documents,  and  retrieval  of  TO  Change  Requests  stored  internally 
as  database  forms,  become  identical  to  the  user.  This  is  an  implementation  of  an  object- 
oriented  paradigm;  TOs  and  Change  Recommendations  are  objects  with  much  of  their  be¬ 
havior  in  common,  but  with  occasional  differences.  This  paradigm  is  independent  of  the  un¬ 
derlying  data  models  and  could  be  implemented  using  a  variety  of  different  data  models. 

Another  aspect  of  an  appropriate  user  interface  paradigm  design  is  related  to  data  access  con¬ 
trol.  The  notion  of  public  and  private  data,  although  not  a  new  idea,  is  beginning  to  take  on 
some  new  value  in  graphical  user  interface  environments.  Users  are  accustomed  to  having 
private  disks,  disk  areas  or  directories  as  well  as  some  sort  of  access  to  more  public,  shaicd 
directories  and  or  databases.  In  AFTOMS,  Tier  2  technicians  may  have  private  copies  of  TOs 
or  sections  of  TOs  in  the  process  of  being  changed.  These  TOs  would  be  considered  private 
data.  Other  examples  of  private  data  include  electronic  mail  messages.  Public  copies  of  the 
most  recent  TO  distributions  are  examples  of  public  data  at  the  TOMA  data  center.  The  user 
interface  model  designed  for  the  Demo  System  represents  specific  private  and  public  data 
entities  as  graphical  icons  on  the  screen.  If  a  user  does  not  have  access  to  a  particular  public 
database,  then  upon  entry  to  the  system,  the  icon  for  that  database  does  not  appear.  This 
simplifies  the  local  environment.  Limiting  access  to  specific  functions  rather  than  to  data  sets 
is  another  dimension  of  data  access  control.  Functional  access  limitations  can  be  obtained  by 
building  customized  menus  for  each  user  class.  Current  windowing  environment  toolkits 
provide  tools  to  create  these  customizations. 

B3.3.1.4  Work  Flow  Modeling 

There  is  increasing  awareness,  especially  by  the  document  management/electronic  publishing 
system  vendors,  for  a  requirement  of  tools  to  assist  managers  and  other  users  in  managing  the 
flow  of  work.  Intergraph  has  implemented  a  scheme  for  assigning  stages  to  documents  as  they 
progress  through  various  development  and  revision  cycles.  In  the  Demo  System,  the  concept 
of  an  electronic  '‘in-box”  was  introduced  to  handle  queued  input  requests  among  users  of  the 
AFTOMS  system.  Change  Requests  can  be  initiated  by  one  user  and  automatically  routed  to 
another  user's  in-box.  The  contents  of  in-boxes  can  be  viewed  or  manipulated,  and  priorities 
can  be  assigned  to  items.  Managers  with  appropriate  privileges  can  view  the  in-boxes  of  their 
staff  as  part  of  the  process  of  monitoring  work  allocation.  The  idea  of  task  allocation  aids  is 
not  new,  however;  newspaper  systems  often  include  such  software  for  handling  allocation  of 
work  from  an  editor  to  the  staff.  Modem  GUIs  make  such  software  much  easier  to  use. 

B3.3.1.5  B+  Enhancement 

Enhancements  to  TO  data,  combined  under  the  name  ”B  +  ”,  can  be  obtained  with  FY89 
technology.  These  enhancements  generally  fall  into  two  distinct  categories  in  AFTOMS: 

•  Customized  views  and  data  navigation  for  Tier  4  maintenance  technicians;  and 
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•  Extensive  cross-referencing  across  TOs  to  provide  for  better  control  over  de¬ 
velopment  and  change  management  at  Tier  2. 

.Hypertext  technology  can  aid  both  of  these  categories.  In  FY89,  commercially  available  end- 
user  hype  next-based  systems  are  mostly  aimed  at  on-line  help  in  computer  systems.  There 
have  also  been  experiments  in  using  hypertext  for  navigation  through  reference  material  by 
students  and  even  for  general  office  communication  and  interaction.  Within  the  past  year, 
there  has  been  a  great  deal  of  activity  centered  around  adding  hypertext  capability-  to  page 
viewing  systems.  Pre-published  pages  in  Page  Description  Language  (PDL)  form  can  be  en¬ 
hanced  with  hypertext  links  to  allow  for  navigation  through  pre-defined  pathways.  Using  the 
latest  caching  techniques,  traversal  across  links  is  swift.  Speed  will  also  improve  with  faster 
workstation  hardware.  These  page-oriented  hvpertext  systems  fall  under  the  category  called 
"on-line  delivery  systems".  On-line  delivery  systems  are  beginning  to  address  the  problem  of 
displaying  customized  views  of  pages;  however  this  capability  is  not  yet  commercially  avail¬ 
able. 

Hypertext  can  also  assist  in  control  of  changes  and  general  cross-referencing  and  indexing. 
Related  sections  of  different  documents  can  be  connected  via  hypertext  links.  Table  of  Con¬ 
tents  and  indexes  can  have  hypertext  links  on  every  item,  allowing  the  reader  to  jump  immedi¬ 
ately  to  the  desired  section  or  index  reference.  While  Table  of  Contents  and  index  links  can 
be  generated  automatically,  related  section  links  generally  require  manual  set  up.  Unfortu¬ 
nately.  most  systems  providing  the  hypertext  capabilities  just  described  do  not  also  include  the 
features  for  data  and  document  management  required  by  AFTOMS.  The  solution  to  this  lack 
of  integration  in  the  Demo  System  was  to  supply  these  hypertext  capabilities  only  in  the  on¬ 
line  delivery  system  and  provide  access  to  that  software  from  all  tiers,  including  Tier  4.  Access 
to  Tier  4  software  by  Tier  2  is  desirable,  since  verification  of  Tier  4  views  must  be  performed  at 
Tier  2.  Ln  the  Demo  System  there  is  a  utility  program  which  inserts  most  reference  links  (as 
well  as  custom  view  information)  automatically  when  it  prepares  TOs  for  delivery.  Once  the 
TOs  are  prepared  for  delivery,  they  can  no  longer  be  edited.  One  of  the  consequences  of  this 
limitation  is  that  the  Tier  2  publications  personnel  cannot  simultaneously  edit  the  TO  con¬ 
tents  and  jump  the  links. 

Despite  the  presumed  advantages  of  using  hypertext  in  many  parts  of  AFTOMS,  analysis  of 
Air  Force -provided  TOs  for  current  weapon  systems  has  shown  that  the  attainment  of  true 
synchronized  control  of  changes  to  related  or  similar  sections  occurring  in  different  TOs  re¬ 
quires  more  powerful  tools  than  hypertext.  The  feature  known  as  ’“change  control",  now 
available  in  one  vendor's  Document  Management  System  (DMS)  and  soon  to  be  available  in 
others,  provides  at  least  a  partial  solution  to  this  complex  problem.  Change  control  allows 
multiple  users  to  contribute  "suggested"  changes,  as  well  as  add  in  the  document  notations  or 
other  explanatory  material  attached  to  the  change.  Each  user’s  change  can  be  separately- 
named  and  individually  accepted  or  rejected  as  part  of  the  final  document.  This  process  takes 
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place  within  the  context  of  the  fully  composed  and  paginated  document  _>n  the  workstation 
screen,  that  is,  in  a  WYSIWYG  environment. 

Another  feature  available  in  a  DMS  environment  provides  for  automatic  inclusion  of  boiler¬ 
plate  text  and  graphics  from  a  source  outside  the  document  itself.  POC  experiments  have 
demonstrated  that  by  combining  the  change  control  and  boilerplate  inclusion  features  (along 
with  some  customizations),  a  system  for  management  of  identical  or  similar  material  across 
documents  can  be  attained.  The  disadvantage  of  such  a  system  is  that  like  material  must  be 
reauthored  or  at  least  reorganized  into  components  so  that  the  software  can  keep  track  of  it 
throughout  years  of  changes.  It  is  not  practical  to  perform  wholesale  changes  on  all  existing 
TOs  although  it  may  be  practical  to  reorganize  existing  TOs  in  a  limited  manner  (e.g.,  sepa¬ 
rate  out  all  warnings,  cautions,  and  notes  that  multiply-occur,  since  these  can  be  easily  identi¬ 
fied  by  their  SGML  tags).  However,  material  that  is  related  in  some  manner,  or  material  that 
describes  the  same  procedure  or  task  in  a  slightly  different  format  (such  as,  material  in  a  Job 
Guide  or  a  Fault  Isolation  manual)  is  much  more  difficult  to  identify,  and  thus,  more  difficult 
to  separate.  Manual  tagging  to  support  such  a  process  would  undoubtedly  involve  prohibitive 
costs,  and  automated  techniques  are  not  yet  available. 

In  summary,  graphical  user  interfaces  based  on  X-W'indows  in  FY89  are  state-of-the-art, 
and  provide  a  possible  solution  to  the  problem  of  running  new  software  on  existing  hardware 
platforms  due  to  the  increasing  availability  of  X- Windowing  upgrade  packages.  Performance 
may  be  an  issue  with  X -Windows,  however.  SGML  support  is  only  partially  available.  Data 
management  and  distributed  data  access  tools  are  available  but  generally  lack  integration 
with  standard  GUIs.  No  one  data  model  stands  out  as  the  model  for  all  AFTOMS  data.  B  + 
enhancement  capabilities  are  within  reach,  although  the  technologies  required  are  not  as  in¬ 
tegrated  as  needed.  Change  control  is  a  difficult  technical  problem  to  which  document  man¬ 
agement  systems  in  FY89  provide  at  least  a  partial  solution. 

B3  3.2  In  P/9I-FY93 

Key  areas  to  examine  in  the  FY91-FY93  time  frame  include:  user  interface  technologies; 
standards;  data  transparency,  distribution  over  networks,  and  model  integration;  groupware 
and  conferencing  technologies;  and  hardware  advances. 

B33.2.1  User  Interface  Technologies 

User  interfaces  in  the  early  nineties  will  gravitate  toward  the  multiple-windowed,  mouse- 
based,  graphical  interface  that  developed  from  the  Xerox  Star-Macintosh  heritage.  GUIs 
will  become  the  accepted  standard  and  will  be  a  vehicle  for  hiding  the  command  language  of 
the  underlying  operating  system.  This  is  important  for  heterogeneous  government  computing 
environments  such  as  AFTOMS  because  it  allows  operating  system  differences  to  be  hidden 
from  the  user.  With  an  operating  system  such  as  UNIX,  which  is  not  known  to  be  user- 
friendly,  it  is  particularly  important.  Many  people  believe  that  the  advent  of  GUIs  will  contin¬ 
ue  to  promote  the  acceptance  of  UNIX  than  any  other  single  factor.  As  UNIX  matures  and 
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new  features  are  added,  these  changes  can  be  more  easily  hidden  from  the  end-user  than  was 
previously  possible. 

The  difficulty  of  programming  these  multi-layer  windowing  GUIs  will  be  alleviated  in  the 
early  nineties  by  the  advent  of  more  advanced  toolkits  and  User  Interface  Management  Sys¬ 
tems. 

New  user  interface  paradigms  will  likely  emerge  in  the  FY91-FY93  time  Fame.  Current 
indications  are  that  these  paradigms  will  take  the  desktop  metaphor  to  new  and  broader  con¬ 
cepts.  This  development  is  aimed  towards  encompassing  more  of  the  user  environment  while 
tailoring  the  user  interface  to  the  user’s  micro-environment.  “Agents”  or  “assistants",  already 
in  use  in  some  systems,  will  come  into  more  common  usage,  both  to  automate  repetitive  tasks 
and  to  allocate  network-based  resources. 

B3.3.2.2  Standards 

The  current  emphasis  in  the  computer  industry  on  open  systems  and  standards  will  continue 
over  the  near  future.  This  will  enchance  the  effectiveness  of  large  systems,  such  as  AFTOMS, 
which  must  depend  on  standards  to  maintain  consistency  and  keep  life  cycle  support  costs  low. 
The  increasing  complexity  of  software  in  addition  to  market  pressures  is  forcing  vendors  to 
cooperate  more  with  each  other.  Even  relatively  small  software  vendors  in  FY89  are  finding 
it  necessary  to  purchase  software  from  other  vendors  to  use  in  conjunction  with  their  own 
products.  CALS  contributes  a  great  deal  to  this  trend  It  is  hoped  that  required  developments 
in  this  environment,  such  as  techniques  for  interactive  SGML  validation,  will  appear  and  re¬ 
ceive  widespread  acceptance. 

By  the  FY93  time  frame,  a  great  deal  more  expertise  will  have  been  developed  in  the  area  of 
SGML  and  more  powerful  tools  will  have  become  available  to  handle  it  in  a  more  transpar¬ 
ent  manner. 

B3.3.2.3  Data  Transparency,  Distribution  and  Integration  of  Technologies 

DMS  and  RDBMS  technologies  are  beginning  to  overlap  capabilities.  DMS  vendors  are  us¬ 
ing  data  management  techniques  to  manage  documents.  Current  trends  in  relational  data¬ 
bases  toward  a  more  object-oriented  approach,  allowing  more  than  traditional  data  to  be 
stored  (including  large  blocks  of  text,  graphics,  and  video),  will  become  more  important  and 
more  mature  in  this  time  frame.  Significant  for  AFTOMS,  the  distributed  technology  being 
developed  currently  by  RDBMS  vendors  should  by  FY93  become  well  integrated  into  object- 
oriented  database  systems.  The  distributed  technology  will  have  advanced  to  being  closer  to 
’’truly”  distributed;  updates  over  disparate  sites  will  be  handled  more  efficiently.  This  trend 
contributes  to  improving  data  access  transparency  to  the  user. 

In  addition  to  general  purpose  object-oriented  databases,  improved  data  models  will  be  de¬ 
veloped  by  this  time  frame  suitable  for  AFTOMS.  For  example,  a  new  type  of  database  cur- 
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rently  being  developed  is  the  ’’hypermedia  server”;  at  least  one  product  has  been  announced 
for  early  FY90.  Such  systems  have  built-in  linkage  capabilities,  can  handle  multiple  media 
forms,  and  are  network-based.  Designing  AFTOMS  around  such  a  model  could  mean  that 
the  navigational  capabilities  provided  at  Tier  4  could  be  made  available  at  all  tiers,  and  could 
be  used  for  indexing  and  retrieval  as  well.  Such  technolog)'  also  could  provide  a  basis  for 
support  of  true  Type  C  data.  The  AFTOMS  design  must  allow  for  future  incorporation  of  this 
neutral  data  for  new  weapons  systems,  and  thus  the  underlying  data  model  must  be  prepared 
to  accomodate  it. 

B3.3.2.4  Groupware,  Conferencing  Technologies 

The  contractor-Air  Force  interface  may  be  aided  in  this  time  frame  by  further  advances  in 
’’groupware”  technology.  With  the  rapid  growth  in  networked  systems,  the  problem  of  multi¬ 
ple  users  working  together  on  design  problems,  documentation,  etc.,  is  receiving  more  atten¬ 
tion.  Advances  in  wide  area  communications  should  provide  better  environments  for  devel¬ 
opments  in  electronic  conferencing  as  well. 

B3.3.2.5  Hardware  Advances 

The  rapid  advances  now  taking  place  in  computer  hardware  technology  show  no  signs  of  let¬ 
ting  up.  The  implications  for  AFTOMS  are  profound.  Plans  must  be  made  now  for  vastly- 
increased  capability  in  the  near  future.  This  fact  has  important  implications  for  the  incorpora¬ 
tion  of  existing  hardware  into  AFTOMS  because  the  faster  that  advancements  take  place,  the 
faster  the  existing  systems  become  technologically  (but  not  necessarily  operationally)  obso¬ 
lete.  Another  consequence  of  rapid  hardware  advances  is  in  software  design.  AFTOMS 
should  tradeoff  current  performance  (if  necessary)  to  incorporate  advanced  software  func¬ 
tionality!  that  is,  it  should  be  designed  to  take  advantage  of  hardware  that  is  likely  to  appear 
two  or  three  years  out  (e.g.,  in  FY94;  not  what  is  available  in  FY91 ).  Failure  to  do  so  will  result 
in  a  lower-quality  system  that  will  not  take  full  advantage  of  the  latest  off-the-shelf  software. 

B3.4  APPROACHES  TO  INTEGRATED  USER  SUPPORT 

This  section  explains  lessons  learned  from  working  with  various  vendor  solutions  to  problems 
similar  to  those  presented  by  AFTOMS.  First,  the  experiences  in  developing  the  Demo  Sys¬ 
tem  will  be  discussed,  followed  by  a  discussion  of  lessons  learned  from  other  hands-on  techni¬ 
cal  evaluations. 

B3.4.1  In  Demo  System 

Appendix  A  identifies  the  major  functionality  of  the  AFTOMS  system.  This  section  summa¬ 
rizes  the  major  lessons  learned  applying  user  interface  approaches  to  link  the  user  with  the 
AFTOMS  functions.  These  observations  are  based  on  limited  viewing  and  usage  of  the  Demo 
System  by  developers  and  typical  Air  Force  users. 

An  important  design  goal  was  to  develop  a  user  interface  that  would  run  in  a  standard  win¬ 
dowing  environment.  This  would  make  it  easy  to  run  the  software  on  multiple  platforms  (or 
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switch  to  additional  platforms  at  a  later  date).  Also,  it  would  minimize  the  training  time  for 
AF  personnel.  X-windows  was  used  as  the  windowing  environment  and  both  these  benefits 
were  realized.  Use  of  the  same  software  running  on  a  standard  windowing  platform  (X- 
windows)  makes  it  easy  to  switch  hardware  platforms  and  use  the  system  with  no  new  training. 
It  really  does  behave  the  same  across  the  different  platforms.  In  the  future,  all  major  worksta¬ 
tion  and  terminal  vendors  will  support  X-windows  and  AFTOMS  will  be  able  to  select  the 
best  hardware  solution  for  its  wide-ranging  user  community’. 

Color  workstations  were  used  in  the  Demo  System.  Experimentation  was  performed  regard¬ 
ing  how  to  make  the  best  use  of  color  in  the  user  interface.  AFTOMS  has  a  few  major  data 
types  (i.e.,  TOs,  Change  Requests,  etc.).  Each  one  was  assigned  a  specific  color.  Major  data 
types  were  identified  and  accessed  via  icon  selection  (which  was  color-coded)  which  seemed 
intuitive  and  easy  to  learn.  Color  coding  the  major  data  types  (e.g.,  TOs  =  blue,  CRs  = 
green)  and  carrying  the  color  schemes  throughout  the  user  interface  to  maintain  consistency 
and  familiarity  worked  very  well. 

With  a  large,  heterogeneous,  multi-function  system  such  as  AFTOMS,  simplicity  of  the  user 
interface  is  essential.  Several  complicated  applications,  such  as  DMS  and  ODS,  have  to  be 
learned  and  used.  These  commercial  applications  were  general  purpose  in  design,  not  devel¬ 
oped  just  for  AFTOMS;  thus,  some  of  their  commands  and  options  were  not  relevant  for  AF¬ 
TOMS  use.  To  keep  the  DMS  and  ODS  user  interface  simple  enough,  the  functionality  was 
reduced  by  disabling  and  or  hiding  many  commands.  This  also  reduces  clutter  and  is  a  good 
technique  for  increasing  user  productivity. 

Finally,  information  presentation  techniques  and  screen  cosmetics  have  a  subtle,  but  pro¬ 
found  effect  on  the  acceptance  of  the  system  by  the  user  community.  Color  can  be  very  bene¬ 
ficial  in  this  area  if  used  properly.  Experience  showed  that  the  percentage  of  the  screen  in 
non-neutral  colors,  especially  bright  colors,  should  be  small.  Large  areas  of  bright  colors  are 
jarring,  distracting,  generally  hard  on  the  eyes,  and  unpopular  with  users.  Small  areas,  such  as 
buttons  or  stripes  of  color  for  accenting  information  are  useful  and  popular  with  users. 

B3.4.2  In  Other  Hands-on  Technology  Evaluations 

Several  commercial  software  products  incorporating  GUI  technology  and  AFTOMS-useful 
functionality'  were  evaluated;  these  included: 

•  A  DMS  product  that  integrated  full  RDBMS  capability’ in  a  Publishing  System; 

•  A  database  user  interface  product;  and 

•  A  hypertext  product 


B3.4.2.1  DMS  Product 

This  software  system  provided  a  user  interface  model  for  work  Cow  control  and  document 
management  as  well  as  a  WYSIWYG  electronic  publishing  system.  The  work  Cow  model  is 
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implemented  by  incorporation  of  a  commercially-available  RDBMS,  but  as  the  internal  pro¬ 
tocol  is  SOL,  other  SQL^-based  databases  could  have  been  used  as  well. 

In  this  system,  documents  are  assigned  states  through  which  they  must  pass  on  their  way  from 
inception  to  publication.  Any  amount  of  information  about  documents  can  also  be  stored  in 
the  database.  Intuitive  retrieval  techniques  are  supplied  for  accessing  documents,  and  users 
are  not  required  to  use  a  query  language.  Representation  of  data  is  a  combination  of  graphi¬ 
cal  icons  and  menus  of  textual  options,  field  values,  etc.  The  interface  is  a  GDI  which  will 
eventually  be  implemented  on  top  of  X- Windows. 

When  the  user  requests  to  view  a  document’s  contents,  the  GULdatabase  environment  tran¬ 
sitions  to  the  normal  electronic  publishing  software.  When  the  document  viewing  or  editing 
is  completed,  the  user  closes  the  document,  and  is  returned  to  the  original  GUI  screen;  the 
transition  between  the  two  environments  is  relatively  smooth. 

B3. 4.2.2  Database  User  Interface  Product 

This  software  product  was  the  result  of  a  joint  development  effort  between  a  Unix  worksta¬ 
tion  vendor,  and  a  RDBMS  vendor.  It  incorporates  a  proprietary  GUI  for  database  querying 
of  management  information.  However,  this  GUI  does  not  support  the  X-  Windows  environ¬ 
ment  and  so  it  is  not  clear  that  the  product  will  remain  on  the  market  in  its  current  form. 
However,  it  does  demonstrate  niceiy  how  a  GUI  can  be  used  to  integrate  technology  products 
and  simplify  system  use. 

B3.4.2.3  Hypertext 

Hypertext-based  on-line  help  systems  are  becoming  popular  add-ins  with  many  new  soft¬ 
ware  products.  With  such  a  help  system,  the  operator  can  use  the  mouse  to  move  the  pointer 
to  the  special  help  icon.  By  selecting  the  icon,  the  system  displays  the  hypertext  help  text  dis¬ 
cussion  of  the  program  relevant  to  the  point  where  it  is  currently  running.  The  help  text  dis¬ 
play  includes  links  to  other  related  material;  and  graphics  also  appear  in  the  help  text. 

Hypertext  languages  are  also  becoming  available.  Some  store  user-defined  text  and  graphics 
in  electronic  ’’cards”  which  make  up  ’’stacks”  of  information.  They  incorporate  an  interactive 
GUI  interface  to  allow  the  user  to  insert  or  change  links,  and  provide  text  and  graphical  edit¬ 
ing  tools  for  manipulation  of  the  contents  of  the  cards.  Such  languages  offer  sufficient  flexi¬ 
bility  to  be  used  for  many  purposes  such  as  prototyping  of  user  interfaces,  which  is  how  this 
capability  was  used  in  the  development  of  the  Demo  System  user  interface. 

B3.5  RISK  ASSESSMENT 

This  section  outlines  the  risks  still  present  in  the  FY91-FY93  time  frame  regarding  the  issues 
related  to  user  support  discussed  above.  First  technological  risks  are  examined  followed  by  a 
discussion  of  business  issues. 
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B3.5.1  Technological  -  System  Buildability,  Usability,  and  Intra-operability 
The  major  technical  challenges  in  AFTOMS  overall  include: 

•  Development  of  a  coherent  data  model  that  will  support  requirements  for  in¬ 
corporation  of  future  neutral  data; 

•  Incorporation  of  SGML  and  conversion  of  existing  TOs; 

•  Support  of  the  high  volume  of  data  across  wide  area  networks; 

•  Development  of  portable  devices  for  on-aircraft  maintenance;  and 

•  Support  for  cross-TO  control  of  changes  that  span  several  TOs. 

Design  of  an  easy-to-use,  consistent  user  interface  for  all  classes  of  AFTOMS  users  is  also  a 
challenge,  but  technically  it  is  less  of  a  challenge  than  those  outlined  above. 

The  selection  of  an  underlying  da'a  model  for  AFTOMS  has  profound  implications  for  user 
d?tn  access,  both  in  capability  and  in  performance.  It  is  difficult  to  envision  the  perfect  data 
model  especially  since  the  operational  concept  of  neutral  data  has  not  yet  been  clarified. 
There  are  considerable  technical  risks  with  trying  to  integrate  DBMS,  DMS,  and  hypertext/ 
ODS  technologies  with  their  inherently  different  underlying  data  models.  However,  such  in¬ 
tegration  may  be  a  lower  risk  alternative  than  inventing  a  special-purpose,  completely  new 
data  model  that  will  support  the  features  of  all  three. 

Although  there  is  some  risk  that  sufficient  standards  will  neither  become  available  nor  inter¬ 
operate  well  in  this  time  frame,  it  looks  as  though  X- Windows-based  GUIs  will  help  stabilize 
the  overall  situation  in  time.  SGML  is  something  of  a  greater  risk  because  of  its  inherent 
complexity.  It  is  not  a  standard  chosen  by  a  wide  customer  base,  nor  by  industry.  There  is  a 
substantial  risk  (at  ieast  during  the  initial  deployment  of  AFTOMS)  that  the  imposition  of 
SGML  will  complicate  the  publications  process.  It  is  sometimes  assumed  that  SGMLtagging 
will  take  care  of  many  indexing  and  linking  problems  automatically,  but  it  is  likely  that  most  of 
these  tags  will  have  to  be  manually  entered  at  considerable  cost.  There  are  artificial  intelli¬ 
gence  research  groups  working  on  semantic  analysis  of  text,  but  this  technology'  is  still  in  its 
infancy'.  An  additional  problem  related  to  change  control  of ’’like  material”  in  existing  TOs  is 
the  identification  of  related  matching,  but  not  identical,  material.  The  POC  analysis  of  cur¬ 
rent  TOs  has  shown  that  SGML  tagging  along  the  lines  of  the  new  Air  Force  DTD’s  based  on 
MIL-STD  28001  will  not  be  sufficient  to  identify  this  type  of  non-identical  but  related  materi¬ 
al.  The  reason  is  that  current  SGML  models  are  based  on  a  structural,  rather  than  a  semantic 
approach.  This  problem  could  become  exacerbated  with  the  conversion  to  neutral  data  need¬ 
ed  to  support  Type  C  TOs. 

Support  of  a  high  volume  of  data  within  AFTOMS  does  not  particularly  relate  to  user  support, 
except  through  its  impact  on  data  availability  and  performance  (See  Section  B8,  Operational 
Utility). 
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The  portable  delivery  device  problem  relates  to  AFTOMS  only  indirectly  in  that  the  deliv¬ 
ered  TO  data  must  be  flexible  enough  to  be  displayed  on  devices  with  relatively  small  screens 
and  low  amounts  of  memory.  For  in-shop  workstations  as  well  as  portable  computers,  the 
user  interface  should  be  designed  to  be  extremely  simple,  requiring  very  few  keystrokes  (and 
possibly  no  mouse)  to  operate.  This  is  not  a  high  technical  risk  in  and  of  itself.  The  risk  occurs 
in  the  development  of  a  portable  system  that  is  really  viable  to  use.  For  example,  if  so  much 
scrolling  is  required  to  reference  one  figure  that  the  technician  spends  more  time  striking  keys 
than  reading  the  information,  then  the  solution  is  not  viable.  In  FY89  it  is  probably  impossi¬ 
ble  to  build  a  viable  portable  system  for  TOs  that  meets  all  other  operational  requirements  of 
the  Using  Commands.  Given  that  by  the  early  90's  technology  will  have  advanced  far  enough 
(especially  in  high-resolution,  flat-panel  displays)  to  support  a  viable  portable  device,  then  it 
remains  for  AFTOMS  to  be  able  to  deliver  TO  data  in  other  than  full-page  form.  This  is 
easily  attainable  even  with  current  technology  and  current  data  models.  All  document  man¬ 
agement  systems,  for  example,  can  produce  SGML  files  which  retain  all  of  the  tags  necessary 
to  reformat  the  text  to  different-sized  displays. 

In  summary,  although  there  are  many  technical  risks  for  AFTOMS  overall,  those  related  to 
user  support  are  not  among  the  highest. 

B3.5.2  Long-Term  Viability 'Supportability 

There  ai  e  several  process  issues  that  pose  risks  for  timely  deployment  of  AFTOMS.  Some  of 
these  issues  are  intermixed  with  technical  issues. 

Separate  specification  and  acquisition  of  an  Air  Force  standard  or  unique  TO  presentation 
system  could  have  a  negative  impact  on  the  overall  integration  of  AFTOMS  systems  at  all 
tiers.  For  example,  accurate  verification  of  multiple  views  of  Tier  4  data,  which  must  be  ac¬ 
complished  at  Tier  2,  may  require  retrofitting  AFTOMS  with  the  TO  presentation  system(s) 
used  at  Tier  4.  The  problems  will  compound  if  more  than  one  TO  presentation  system  is  im¬ 
plemented. 

There  are  risks  involving  decisions  on  some  critical  overall  directions.  Certain  decisions  on 
the  sy  stem  model  for  AFTOMS  will  affect  the  job  functions  of  personnel.  Whether  technical 
publications  technicians  directly  implement  TO  changes  themselves  or  not  profoundly  affects 
how  the  system  is  designed.  Whether  Tier  4  technicians  can  communicate  directly  with  Tier  2 
technicians  about  the  nature  of  a  TO  change  also  affects  how  the  system  is  designed.  Whether 
support  for  a  direct  interactive  interface  between  Tier  2  personnel  and  the  contractor  should 
be  included,  and  whether  that  support  should  include  interactive  TO  editing,  affects  the  sys¬ 
tem  design.  If  these  decisions  and  others  are  delayed  too  long,  it  will  be  difficult  to  predict 
what  type  of  system  will  in  fact  be  built. 

There  are  some  process  implications  involved  with  adopting  a  model  of  TO  traversal  at  Tier  4 
which  is  based  on  customized  views.  These  implications  are  difficult  to  anticipate  within  the 
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current  environment.  There  is  also  a  lack  of  experience  elsewhere  with  this  idea  to  test  its 
viability.  It  could  especially  be  a  problem  regarding  coordination  with  paper  copies. 

Requirements  for  implementation  of  AFTOMS  on  existing  hardware  platforms  should  be 
very  carefully  considered  and  approached  with  some  degree  of  caution,  as  there  is  risk  in¬ 
volved  here,  too.  It  is  always  tempting  to  state  that  a  more  limited  version  of  the  software  and 
therefore  of  the  user  interface  can  be  implemented  on  more  limited  hardware.  Features  can 
be  omitted,  slower  speed  can  be  tolerated,  programs  that  cannot  run  at  all  due  to  memory  and 
other  limitations  can  be  made  unavailable,  etc.  There  are  some  problems  with  such  an  as¬ 
sumption: 

•  In  genera],  software  is  not  designed  such  that  pieces  can  be  removed  easily.  If 
the  software  is  designed  from  the  beginning  to  be  modular  enough  to  allow 
such  massive  reconfiguration,  and  object-oriented  techniques  can  certainly  aid 
in  this  process,  the  associated  costs  should  be  carefully  weighed  against  the  sup¬ 
posed  advantages;  and 

•  A  more  subtle  problem  results  from  the  fact  that  separate  user  interfaces  may 
have  to  be  designed  for  the  separate  environments  thus  increasing  complexity  in 
the  user  interface  and  adding  integration  risk. 

The  second  requires  further  explanation.  For  example,  there  might  be  an  expectation  that 
once  a  full  GUI  implementation  on  state-of-the-art  workstations  is  operational,  that  it 
would  be  easy  to  implement  a  subset  of  that  interface  on  character-based  terminals.  Unfortu¬ 
nately,  that  is  not  generally  the  case  unless  the  interface  is  very  simple.  The  reason  is  that  the 
two  environments  are  so  different  in  capability  that  a  dynamic  user  interface  paradigm  de¬ 
signed  for  the  high-end  environment  will  simply  not  translate  well  to  lower-end  platforms 
(e.g.,  graphical  icons  cannot  be  displayed  on  a  character-based  machine).  Even  if  the  icons 
could  be  represented  in  some  fashion  using  characters,  the  tools  to  perform  the  dynamic 
GUI-like  manipulations  are  not  available  to  the  software  developer  in  the  older  environ¬ 
ment.  In  summary,  using  older  environmental  models  to  drive  new  system  design  can  lead  to 
lost  opportunities,  especially  given  the  rapid  pace  of  technological  advancement.  Moreover, 
integration  of  existing  environments  and  platforms  into  a  new  design  has  to  be  done  carefully 
in  order  to  avoid  creating  an  inferior  overall  design,  as  well  as  accumulating  high  software 
development  and  support  costs. 

B3.6  RISK  ABATEMENT 

Since  dynam ic  interaction  is  so  important,  a  proven  method  for  risk  abatement  for  user  inter- 
fa  ce  design  is  early  prototyping.  It  is  very  difficult  to  evaluate  user  interfaces  described  on 
paper,  but  it  is  very  easy  to  evaluate  working  models. 

Another  general  approach  to  risk  abatement  in  complex  systems  is  to  simplify,  or  phase-in 
the  requirements.  For  example,  it  may  be  too  early  to  try  to  anticipate  the  needs  of  a  complete 
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neutral  data  TO  management  system.  A  data  model  sufficient  to  support  current  B  4-  require¬ 
ments  could  be  built  in  anticipation  of  later  conversion  of  tne  data  to  a  new  neutral  model. 

This  simplification  could  extend  to  SGML.  If  the  decision  could  be  mao®  on  how  much  data 
about  TO  structural  elements  such  as  sections,  tasks,  and  steps  were  really  needed,  it  might 
turn  out  that  less  Lagging  than  currently  anticipated  s  actually  required.  Related  to  this  issue 
is  the  granularity  question;  tha.  is,  what  granularity  is  required  to  retrieve  TO  information, 
not  at  Tier  4,  but  by  manager-users  at  Tier  2.  For  example,  if  the  task  or  subsection  level  is 
sufficient  granularity  (rather  than  the  individual  step),  then  that  decision  vastly  simplifies 
tagging  and  therefore  conversion  of  existing  documents:  there  are  easily  twenty  times  as  many 
steps  in  TOs  as  there  are  tasks.  (Identical  components  such  as  boilerplate  paragraphs  can  be 
handled  inside  a  document  management  environment  using  different  mechanisms  and  do  not 
need  to  be  tied  to  Tier  2  retrieval  requirements.) 

Another  simplification  to  abate  risk  involves  restriction  of  customized  view  options  in  order 
to  simplify  verification.  The  more  important  views  could  be  selected  and  implemen  ed  first, 
then  the  other  view  options  could  be  phased  in  later  once  experience  is  gained  and  benefits 
are  evaluated. 

Flexibility  should  be  built  into  the  system  to  allow  for  unanticipated  problems  and  alterations. 
For  example,  authorization  chains  for  Change  Requests  should  be  fully  editable  by  autho¬ 
rized  users.  It  may  prove  prudent  to  allow  multiple  data  models  to  coexist  in  the  system. 

Standards  should  be  used  wherever  possible  and  practical,  although  not  to  the  extent  that  they 
constrict  the  system. 

Regarding  the  concern  of  developing  an  integrated  system  despite  separate  development  acti¬ 
vities  for  AFTON1S  and  end-user  presentation  systems,  the  risk  can  be  reduced  by  defining  a 
standard  ATTOMS  data  interface  to  Tier  4  and  by  working  closely  with  the  Using  Com¬ 
mands,  rather  than  in  isolation. 

There  are  risks  associated  with  the  incorporation  of  existing  equipment  into  AFTOMS.  De¬ 
sign  of  a  different  user  interface  using  a  different  paradigm  for  the  existing  equipment  is  often 
the  approach  taken.  This  can,  however,  lead  to  higher  development  costs  as  well  as  the  pres¬ 
ence  of  multiple  user  models  within  the  same  system.  A  better  solution  to  both  the  multiple 
user  model  problem  and  the  higher-cost  reconfigurable  software  problem  is  to  develop  one 
version  of  the  software  and  user  interface  that  will  run  on  all  hardware  platforms  in  the  sys¬ 
tem.  This  solution  requires  upgrading  the  existing  hardware  where  practical  to  a  poir.t  where 
it  can  run  the  standard  system  software  unmodified.  Such  upgrade  possibilities  are  available 
and  practical  even  in  FrY89,  mostly  due  to  the  prevalence  of  standards  such  as  UNIX  and  X- 
Windows. 

The  broad-ranging  process  decisions  such  as  those  involving  job  definitions,  neutral  data 
support,  interactive  vs.  batch  publishing,  incr  rporation  of  existing  equipment,  etc.,  need  to 
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SECTION  B4: 

Use  of  Electronic  Communications 


B4.1 


SCOPE  AND  RELEVANCE 


AFTOMS  is  a  system  of  systems  that  will  require  electronic  communications  to  support  data 
distribution  both  within  and  between  tiers.  The  communications  architecture  providing  this 
function  must  be  designed  to  offer  responsive  performance  and  throughput  capacity  while  at 
the  same  time  appearing  to  be  transparent  to  the  user. 

B4.1.1  Communication  Requirements  Overview 

The  resulting  AFTOMS  computer  hardware  and  software  configuration  is  expected  to  be  an 
integrated  blend  of  heterogeneous  systems.  These  will  include:  newly  AFTOMS-acquired 
systems  running  document  management,  data  administration,  and  other  applications;  existing 
systems,  including  the  IBM/Amdahl-based  LMTOS  and  DEC-based  ATOS  (until  absorbed 
or  replaced);  user  work  area  systems  based  on  Z-248  and  successor  PCs;  and  probably  ad¬ 
vanced  digital  TO  presentation  systems  based  on  a  future,  still-undefined  architecture.  En¬ 
suring  data  transfer  and  interoperability  will  require  strict  adherence  to  DoD  and  emerging 
ISO  standards  and  comprehensive  advanced  planning. 

Communications  can  no  longer  be  treated  as  a  standalone  service  w'hich  is  designed  to  sup¬ 
port  applications  externally  such  as  file  transfer.  New  applications  developed  for  AFTOMS 
will  require  communications  to  provide  embedded  transport  and  routing  functions  for  dis¬ 
tributed  applications.  These  include  database  applications  involving  multiple,  distributed 
processors.  Each  of  these  applications  will  require  definition  of  pre-established  and  adhoc 
client-server  relationships.  Selection  of  standards  and  vendor  offerings  for  both  hardware 
and  software  must  be  directed  with  distributed  rather  than  centralized  operations  in  mind. 

The  AFTOMS  network  will  consist  of  LANs  serving  intra-tier  requirements  and  long-haul, 
wide  area  communications  providing  paths  between  tiers.  FIGURE  B4-1  illustrates  local 
and  wide  area  communication  requirements  within  the  four  AFTOMS  tiers. 

B4.1.2  Traffic 

AFTOMS  communication  traffic  will  be  derived  from  the  functions  that  need  to  be  per¬ 
formed  within  and  between  tiers.  The  primary  traffic  types  will  be  electronic  mail,  file  trans¬ 
fer,  transaction  processing,  and  on-line  conferencing. 

ELECTRONIC  MAIL 

Electronic  mail  provides  formal  (record)  and  informal  messaging  services  between  all  AF¬ 
TOMS  personnel  and  facilities.  Electronic  mail  is  expected  to  expand  into  other  services 
which  include  the  ability  to  append  binary  files  and  graphic  images  to  the  main  text  transmis¬ 
sion  for  routing  via  the  mail  network. 

FILE  TRANSFER 

File  transfers  will  consist  of  technical  order  document  files.  Short  file  transfers  (under  100K 
bytes)  include  change  request  packages,  time-compliant  TOs  (TCTOs)  and  administrative 
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database  summaries.  Long  file  transfers  (over  100K  bytes)  will  include  TOs  where  the  aver¬ 
age  TO  file  size  is  3MB  for  100  pages,  composed  of  609c  text  and  409c  illustrations. 


FIGURE  B4-1.  AFTOMS  LOCAL  AND  LONG-HAUL  COMMUNICATION 

REQUIREMENTS 


TRANSACTION  PROCESSING 

Database  queries,  postings  associated  with  profile  registration,  and  program  management 
applications  (plans,  schedules,  status  report,  and  directories)  will  reauire  network  support  of 
on-line  transaction  processing. 

COSFERESCINC 

Conferencing  will  allow  AFTOMS  personnel  and  contractors  to  review  and  comment  on  doc¬ 
uments  while  on-line  with  all  responsible  parties.  Proposed  TO  edits  can  be  distributed  and 
marked  on  screen  for  all  to  review.  Electronic  conferencing  is  considered  an  alternative  to 
face-to-face  meetings. 

FIGURE  B4-2  shows  the  intra  and  inter-tier  traffic  types  which  will  traverse  the  AFTOMS 
networks. 

B4.1.3  Connectivity 

The  network  topology  required  to  support  AFTOMS  will  require  intra  and  inter-tier  compo¬ 
nents. 
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FIGURE  B4-2.  AFTOMS  TRAFFIC  TYPES 
B4.1.3.1  Intra-tier  Connectivity 

Intra-tier  connectivity  will  be  provided  by  LANs  and/or  standalone  systems  at  that  tier.  It  is 
expected  that  AFTOMS  will  require  the  installation  of  departmental  LANs  (generally  under 
10  workstations)  within  most  tiers  to  support  the  AFTOMA,  TOCs,  TOMA  Data  Centers, 
CTODOs,  and  automated  work  areas.  New  LANs  will  adhere  to  Air  Force  Unified  Local 
Area  Network  Architecture  (ULANA)  I  and  later  ULANA  II  specifications.  In  addition, 
connection  between  LANs,  within  the  same  tier,  will  require  a  bridging  service  using  existing 
base  backbones.  In  the  case  of  ALCs,  a  broadband  LAN  (LOGLAN)  is  already  in  place  to 
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provide  such  a  service.  AFLC  has  also  installed  a  similar  LAN  to  support  HQ  AFLC.  Base 
facilities  will  need  to  be  examined  on  a  case-by-case  basis  to  determine  their  current  and 
planned  communications  facilities  and  services.  Intra-tier  communications  will  consist  of  the 
following: 

TIER  1  (WITHIN  AFTOMA  ): 

Provides  AFTOMS-related  management  informarion  functions  for  the  support  of  the  total 
administration  ot  AFIOMS  as  well  as  the  creation  of  policy  TOs,  and  centralized  directory 
production. 

TIER  2  (WITHIN AND  BETWEEN  TOMAs): 

TOMA  will  require  the  capability  to  store,  retrieve,  and  edit  individual  TOs  within  their  de¬ 
partment  work  group  as  well  as  exchanging  TOs  and  information  with  other  TOMA  at  the 
same  location  (i.e.  ALC).  This  capability’  will  also  support  incoming  and  outgoing  communi¬ 
cations  to  the  CTODOs  and  contractors.  Connections  to  the  AFTOMS  Data  Centers  serving 
AFLC  TOMA  will  be  extremely  critical  components.  The  connections  will  be  the  principal 
means  by  which  the  individual  TOMA  will  transfer  their  TO  suites  to  the  Data  Center  for 
selective  printing,  archiving,  directory  services,  creation  of  optical  media  for  distribution,  and 
other  means  of  transferring  TO  management  and  content  data  to  the  CTODOs.  In  some 
cases  the  Data  Center  may  also  provide  a  centralized  communication  gateway  function  to 
other  tiers. 

TIER  3  (WITHIN  THE  CTODO): 

The  base  level  CTODOs  are  expected  to  vary  in  size  and  complexity  since  their  function  will 
be  related  to  the  role  of  the  base  or  depot  which  it  supports.  In  all  cases,  however,  there  will 
be  a  required  baseline  capability'  for  an  administration  workstation,  printing,  communica¬ 
tions,  and  on-line  access  of  TO  suites.  The  CTODO  will  process  profile  registrations,  coordi¬ 
nate,  log.  and  transmit  change  requests  on  behalf  of  its  work  areas  and  offer  on-line  access  to 
its  TO  database  for  automated  work  areas. 

TIER  4  (WITHIN  W'ORK AREAS): 

Automated  work  areas  at  Tier  4  will  use  their  LAN  to  accept  TOs  (via  optical  disk  or  CTODO 
downloads),  perform  directory  searches,  and  print  TOs  on  site.  Additionally,  the  work  area 
users  will  be  able  to  coordinate  change  requests  and  registrations  within  the  work  area  prior 
to  contacting  the  CTODO. 

B4.1.3.2  Inter-Tier  Connectivity 

Inter-tier  communications  will  provide  connectivity  between  remote  locations.  Since  bulk 
transfer  of  TOs  will  be  accomplished  by  physical  distribution  of  optical  disks,  the  long-haul 
communications  resource  will  be  used  to  transmit  electronic  mail,  transactions,  short  file 
transfers,  and  occasionally  complete  TOs.  The  nature  of  this  traffic  is  ideally  suited  for  a 
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packet  network  such  as  the  Defense  Data  Network  (DDN).  The  use  of  the  DDN  for  long-haul 
data  traffic  coincides  with  current  Air  Force  and  DoD  directives.  Alternatives  to  the  DDN 
would  be  use  of  dial-up  and 'or  leased  circuits.  In  the  case  of  heavy  traffic  circuits  such  as 
those  between  ALCs,  dedicated  trunks  may  prove  to  offer  greater  performance  for  large  file 
transfers  at  a  lesser  cost.  Inter-tier  communications  will  consist  of  the  following: 

FROM  TIER  1: 

The  AFTOMA  will  need  to  distribute  profile  registrations,  policy  TOs,  and  coordinate  TO 
status  and  change  requests  with  all  Tier  2  TOMAs.  The  AFTOMA  will  also  communicate 
directly  with  the  base  CTODO  on  administrative  issues  which  include  profile  registration, 
status  reports,  and  on-line  master  directory  services. 

FROM  TIER  2: 

All  Tier  2  facilities  will  need  to  communicate  with  the  AFTOMA  in  response  to  administra¬ 
tive  issues  involving  registration  acknowledgements,  status  reports,  program  plans,  and 
change  notices.  In  addition  TOMAs  will  require  long-haul  connectivity  to  other  TOMAs  that 
contribute  TOs  to  their  weapon  system  suite.  Tier  2  TOMAs  will  communicate  with  Tier  ? 
CTODOs  to  coordinate  profile  registrations  and  distribute  TCTOs  and  change  packages. 

FROM  TIER  3. 

Tier  3  CTODOs  will  transmit  profile  requests,  administrative  data,  and  database  queries  to 
the  AFTOMA  Change  requests,  status,  and  configuration  reports  will  be  sent  to  Tier  2  TO¬ 
MAs.  TOs,  TCTOs,  change  packages,  and  change  request  acknowledgements  will  be  trans¬ 
mitted  to  automated  Tier  4  work  areas  that  have  LAN  access  to  the  CTODO. 

FROM  TIER  4: 

Automated  Tier  4  systems  that  have  telecommunications  access  to  the  CTODO  will  provide 
on-line  profile  registration,  change  requests,  and  database  queries  (for  TO  status,  directories, 
availability  dates,  etc.) 

FIGURE  B4-3  shows  network  standards  and  transmission  resources  that  offer  the  potential 
of  meeting  AFTOMS  data  communications  requirements. 

B4.1.4  Performance 

Required  performance  will  drive  the  final  communications  architecture  selected  to  support 
AFTOMS.  Formal  analysis  of  expected  user  requirements  in  this  area  were  not  undertaken. 
However,  it  is  reasonable  to  use  widely  accepted  benchmarks  established  for  commercial 
data  network  design.  Tfansaction  query/response  transit  times  under  five  seconds  and  short 
file  transfers  under  five  minutes  are  reasonable  targets  and  within  reach  of  current  technology 
for  wfde  area  communications.  Transmission  time  of  average  sized  TOs  should  be  in  the 
range  of  5-10  minutes  to  be  considered  reasonable  to  a  typical  user.  This  would  require  a 
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dedicated  transmission  channel  of  at  least  56  Kbps.  Bulk  transfer  of  average  TOs  would 
swamp  low-to-medium  speed  (under  56  Kbps)  communications  resources.  Off-peak  trans¬ 
mission  of  TOs,  when  needed,  may  be  feasible  at  these  rates.  Transmission  of  bulk  TOs 
would  require  high  bandwidth  (T-carrier)  in  order  to  accommodate  regular  delivery  in  min¬ 
utes  rather  than  hours.  LAN  transmission  rates  for  both  Ethernet  (10Mbps)  and  Token  Ring 
(4  and  16  Mbps)  offer  greater-than-specified  performance  for  intra-tier  communications. 
Consideration  should  be  given  to  keeping  LANs  populated  at  a  department  size  (under  10 
workstations)  for  demanding  traffic  associated  with  CAD/CAM  and  document  management 
systems.  LAN  transmission  rates  of  100Mbps  promised  by  Fiber  Data  Distribution  Interface 
(FDDI)  will  offer  a  response  time  comparable  to  magnetic  hard  disk  access. 


FIGURE  B4-3.  NETWORKS  SUPPORTING  AFTOMS  COMMUNICATIONS 


B4.2  STATE  OF  INTEGRATION  FEASIBILITY 

Telecommunications  standards  and  technology  available  today  offer  the  capability  to  support 
projected  requirements  of  AFTOMS.  This  is  due,  in  part,  to  the  commercial  availability  of  a 
relatively  mature  set  of  DoD  communications  protocols  and  the  current  technology  drive  to¬ 
wards  distributed  processing  amongst  both  local  and  remote  LANs. 

B4.2.1  Standardization  and  Interoperability  Issues 

The  Air  Force  has  established  new  system  implementation  guidelines  by  publishing  its  long 
range  plans  for  the  Local  Information  Transfer  Architecture  (LITA)  and  the  Long-Haul  Infor¬ 
mation  Transfer  Architecture  (LHJTA)  as  part  of  the  Air  Force  Information  System  (AFIS). 
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Both  documents  call  for  a  transition  from  the  DoD  protocols  to  the  ISO  suite  as  specified  in 
the  Government  Open  Systems  Interconnection  Profile  (GOSrP).  GOSIP  will  become  a 
mandatory  Federal  Information  Processing  Standard  (FIPS)  for  agencies  in  August  1990. 
Plans  include  upgrading  base  switching  and  transmission  facilities  as  well  as  long-haul  net¬ 
works  such  as  the  DDN  and  DSN.  All  future  automation  systems  such  as  AFTOMS  will  need 
to  be  developed  in  concert  with  these  initiatives.  This  will  require  strict  compliance  to  DoD 
standards  (near  term)  with  a  clear  migratory  path  to  ISO.  Systems  should  be  selected  that 
support  all  digital  switching  and  transmission  as  well  as  common  access  to  digital  services  such 
as  ISDN.  The  Air  Force  and  the  National  Institute  of  Standards  and  Technology  (NIST)  are 
currently  validating  ISDN  and  ISO  standards  at  Mather  AFB. 

Selection  of  AFTOMS  communications  equipment  should  be  based  on  the  ULANA/LITA 
and  DDN/LHITA  requirements.  This  direction  will  allow  AFTOMS  to  be  in-line  for  interop¬ 
erability  with  new  systems  and  network  upgrades  via  planned  gateways  being  developed  by 
NIST. 

Standard  protocols  which  define  physical  connectivity  through  the  transport  layer  are  mature 
and  offer  wide  vendor  support.  These  include  IEEE  802.3  (Ethernet),  802.4  (Token  Bus)  and 
802.5  (Token  Ring)  as  well  as  CCITT  X.25.  The  DoD  TCP/IP  suite  supports  internet  routing 
and  reliable  transport.  TCP/IP  is  strongly  recommended  above  LAN  and  X.25  protocol  im¬ 
plementations. 

DoD  standards  for  E-Mail,  file  transfer  (FTP),  and  virtual  terminal  (TELNET)  are  widely 
available  and  are  often  bundled  with  the  UNIX  operating  system.  ISO  has  established  CCITT 
X.400,  file  transfer,  access  and  management  (FTAM),  and  virtual  terminal  protocol  (VTP)  for 
these  services.  Application  developers  have  been  quick  to  endorse  X.400.  ISO  products  in 
this  area  are  just  beginning  to  be  offered  by  a  limited  number  of  vendors.  Near  term  (FY 
91-FY93)  AFTOMS  systems  may  require  adherence  to  a  subset  of  the  DoD  suite  until  suitable 
ISO-compliant  software  meets  DoD  approval.  This  is  particularly  true  for  the  replacement  of 
TCP  by  the  ISO  TP4  transport  protocol. 

B4.2.2  State  of  the  Technology 

Other  than  electronic  conferencing  applications,  hardware  and  software  is  currently  available 
to  meet  AFTOMS  communications  requirements.  Electronic  conferencing  application  soft¬ 
ware,  although  offered,  is  generally  restricted  to  a  homogeneous  workstation  population. 

EEEE  LAN  standards  are  used  by  most  workstation  vendors  with  Ethernet  being  the  most 
popular.  The  UNIX  operating  system  environment  usually  includes  TCP/IP  service  on  top  of 
the  LAN  protocols.  Similarly  SMTP,  TELNET,  and  FTP  are  provided  as  part  of  the  applica¬ 
tion  layer  suite.  The  Internet  Protocol  (IP)  socket  mechanism  is  commonly  used  to  support 
distributed  applications. 

Bridges  and  gateways  used  to  connect  LANs  offer  X.25  and  asynchronous  communications 
support  for  connecting  remote  locations.  The  ULAN  A I  product  list  includes  several  vendor 
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products  in  this  area.  Standalone  X.25  host  interface  cards  to  connect  single  hosts  or  worksta¬ 
tions  are  available  from  most  vendors.  Full  service  interoperability  with  other  DDN  hosts  will 
require  DDN  Standard  X.25.  DDN  Standard  X.25  provides  additional  features  which  allow 
communications  with  existing  hosts  using  BBN  1822  protocol.  DDN  X.25  allows  subscribers 
to  use  the  network;  however,  TCP/IP  will  be  required  for  systems  to  communicate  across  mul¬ 
tiple  subnets  of  the  DDN  allowing  TCP  connections  to  cross  IP  gateways. 

An  alternative  to  the  DDN  is  using  dial-up  or  leased  lines  to  connect  AFTOMS  tiers.  This 
restricts  performance  and  accessibility  to  all  sites.  Using  the  DDN,  all  AFTOMS  facilities 
would  be  networked  together  and  communicate  as  required.  Hardware  products,  which  in¬ 
clude  modems,  bridges,  gateways,  and  X.25  cards,  are  commercially  available  to  support  this 
alternative  in  either  an  asynchronous  or  synchronous  X.25  mode.  ISDN  host  interface  cards 
offering  basic  rate  interface  (64  Kbps)  data  service  are  being  tested  and  will  provide  an  addi¬ 
tional  network  access  alternative  when  ISDN  is  fully  supported  by  the  local  telephone  com¬ 
panies  (telcos). 

B4.2.3  Security 

Secure  facilities,  secure  networking  and  possibly  trusted  computer  systems  will  be  required 
for  protecting  classified  TO  data.  Local  facilities  will  have  physical  access  control  devices, 
software  passwords  and  access  codes,  and  perhaps,  TEMPEST-certified  facilities  and  work¬ 
stations.  Separate  secure  networks  could  be  developed  to  fulfill  transmission  requirements; 
however,  current  communication  trends  are  to  integrate  this  service  into  a  single  multi-level 
secure  environment.  TCP/IP  subscriber  systems  can  utilize  DoD  E3  devices  (e.g.  BLACK- 
ER).  BLACKER  will  allow  multi-level  security  for  data  transmission  through  the  DDN. 
BLACKER  does  not  encrypt  the  traffic  on  the  local  loop,  or  in  this  case,  the  LAN.  The  use  of 
BLACKER  on  the  DDN  appears  to  be  the  most  appropriate  secure  networking  solution  for 
AFTOMS  during  the  next  3-5  years.  Use  of  the  Secure  Telephone  Unit  (STU)m  offers  near- 
term  security  for  connections  made  over  dial-up  or  leased  circuits.  The  NSA  Secure  Data 
Network  System  (SDNS)  initiative  offers  much  promise  in  the  area  of  offering  a  total  end-to- 
end  solution  for  both  local  and  remote  communications.  Hosts  or  LANs  with  SDNS  devices 
can  communicate  securely  over  any  transmission  medium  or  network  by  mutually  exchanging 
keys.  Host  systems  which  use  SDNS  devices  will  be  required  to  use  GOSIP  protocols  includ¬ 
ing  TP4.  Further  study  in  this  area  may  indicate  that  classified  TO  data  should  be  distributed 
physically  using  courier  delivery  (see  Section  B2,  Handling  and  Conversion  of  Heterogeneous 
Technical  Order  Data,  for  more  detail). 

B4.3  PARTICULAR  INTEGRATION  APPROACHES  USED 

B4.3.1  In  Demo  System 

The  communications  requirements  of  the  Demo  System  were  met  by  department-sized  LANs 
representing  AFTOMS  tiers.  Inter-tier  communications  were  provided  by  the  same  LAN. 
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Wide  area  transmission  using  dial-up,  leased  lines,  or  packet  networks  was  not  included  in  the 
Demo  System  configuration. 

TCP/IP  on  top  of  Ethernet  and  Token  Ring  was  used  as  the  standard  transport  protocol  for 
the  Demo  System.  Performance  provided  by  the  Ethernet  to  satisfy  intra-tier  communica¬ 
tions  proved  to  be  within  stated  requirements. 

The  major  workstation  vendors  used  in  the  Demo  System  offered  networking  software  and 
products  that  supported  DDN  X.25  connectivity.  Several  third  parties  have  similar  products. 
The  Network  File  System  (NFS),  an  industry  de  facto  standard,  was  available  from  all  vendors 
and  was  used  successfully  throughout  for  transparent  file  access  across  all  workstations 'serv¬ 
ers  on  the  LAN. 

B4.3.2  Other  Assessments  for  FY91-FY93 

Major  workstation  vendors  used  in  the  Demo  System,  as  well  as  several  others,  were  re¬ 
searched  to  determine  their  support  for  the  ISO  protocol  suite.  Each  manufacturer  is  contin¬ 
uing  DoD  protocol  products  and  has  plans  to  fully  develop  a  complete  ISO  capability  in  paral¬ 
lel.  The  most  significant  effort  has  been  the  development  of  X.400  compliant  software  for 
E-Mail  and  message  handling  services  needed  for  the  group  work  environment.  Manufactur¬ 
ers  were  found  to  be  pushing  the  development  of  FDDI  LAN  products  for  100Mbps  trans¬ 
mission  rates. 

B4.4  RISK  ASSESSMENT 

The  following  issues  are  considered  risks  that  need  to  be  addressed  by  AFTOMS  communica¬ 
tions  planners: 

•  Traffic  loads  cannot  be  carried  by  specified  transmission  facilities.  Improper 
sizing  and  protocol  selection  of  the  transmission  facilities  will  cause  bottle¬ 
necks,  delay's,  and  unreliable  user  service.  Network  planning  will  require  simu¬ 
lating  or  modeling  AFTOMS  projected  traffic  loads  both  within  and  between 
tiers.  Traffic  loading  information  will  also  be  required  as  part  of  the  User  Re¬ 
quirements  Data  Base  (URDB)  that  needs  to  be  submitted  for  subscription  to 
the  DDN. 

•  Existing  systems  cannot  interoperate  with  AFTOMS  applications.  Protocols 
and  communications  software  used  by  existing  systems  may  be  incapable  of  in¬ 
tegration  into  the  planned  AFTOMS  communication  architecture.  Existing 
TO  systems,  such  as  ATOS,  will  need  to  be  examined  to  determine  their  level  of 
integration  and  communications  interfaces  to  AFTOMS  LAN  and  long-haul 
services. 

•  DDN  resources  may  be  unavailable  for  AFTOMS  wide  area  networking.  Sub¬ 
scribers  to  the  DDN  need  to  coordinate  their  request  for  service  through 
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AFCC  and  DCA.  The  DCA  Defense  Communications  System  Data  Systems 
(DCSDS)  requires  accurate  and  complete  system  information  to  properly  plan 
and  implement  DDN  service.  The  process  of  host  subscription  to  the  DDN  is 
approximately  a  24-month  process.  FIGURE  B4-4  shows  the  steps  required 
for  host  subscription  to  the  DDN. 


FIGURE  B4-4.  STEPS  REQUIRED  FOR  HOST  SUBSCRIPTION  TO  THE  DDN 


•  Protocol  selection  may  not  allow  full  GOSIP  compliance.  During  the  transition 
to  GOSIP,  the  DoD  protocol  suite  will  provide  the  most  comprehensive  vendor 
support  and  DoD  host  interoperability  for  the  near  term.  Planners  must  be 


B4-10 


careful  to  select  system  vendors  that  offer  full  support  and  upgrade  plans  to  ISO 
and  should  use  compliant  ISO  products  wherever  feasible. 

•  Base-level  communications  facilities  may  not  provide  sufficient  access  or  back¬ 
bone  transmission  services.  AFTOMS  base  installations  run  the  risk  of  field¬ 
ing  state-of-the-art  systems  at  bases  undergoing  significant  upgrades  to  their 
premise  wiring,  switching  systems,  and  long-haul  transmission  resources. 

•  New  applications  software  may  be  unable  to  address  underlying  communica¬ 
tions  protocols.  Applications  developed  for  AFTOMS  will  need  to  interoper¬ 
ate  in  a  distributed  environment.  Development  without  a  clearly  specified 
communication  protocol  suite  during  the  GOSIP  transitional  period  can  im¬ 
pair  future  integration  with  other  CALS  systems. 

B4.5  RISK  ABATEMENT 

•  Perform  network  management  traffic  study.  Message  lengths  and  sizes,  fre¬ 
quency-  of  transmission,  and  destination  should  be  projected  and  modeled  for 
proper  link  sizing.  LAN  hardware  and  long-haul  access  should  be  specified  as 
a  result.  In  addition,  performance  requirements  should  be  confirmed  through 
adequate  human  factors  testing. 

•  Develop  interface  specifications.  An  AFTOMS  system  interface  specification 
should  be  developed  in-line  with  the  ULANA  LJTA  and  LHJTA  objectives. 
Existing  systems  integration  studies  should  be  conducted.  In  the  case  of  those 
systems  retained  as  pan  of  AFTOMS,  protocol  converters,  gateways,  and  com¬ 
munications  software  must  be  examined  for  connecting  these  systems.  Part  of 
this  effort  should  determine  the  cost  and  benefits  associated  with  integrating 
the  system  or  leaving  it  in  a  standalone  mode. 

•  Undertake  initial  discussions  with  AFCC  and  DCA.  AFTOMS  planners 
should  initiate  discussions  with  AFCC  and  DCA  over  the  requirements  and 
planning  associated  with  DDN  subscription.  Use  of  dial-up  or  leased  facilities 
and/or  WANS  may  be  needed  to  meet  some  requirements. 

•  Implement  DoD  protocols  from  physical  layer  through  TCP/IP.  AFTOMS 
should  select  implementation  of  the  full  DoD  protocol  suite  through  TCP/IP. 
This  will  allow  GOSIP  compliance  except  for  the  TP4  transport  protocol.  Con¬ 
version  to  TP4  may  be  done  at  a  later  date  once  the  current  debates  over  its 
merits  are  settled.  It  is  recommended  that  TCP/IP  on  top  of  the  LAN  and  X.25 
protocols  be  required.  This  will  allow  full  interoperability  on  the  DDN  and 
allow  initial  secure  systems  to  use  BLACKER  devices.  Use  of  X.400,  FTAM, 
and  VTP  standards  should  be  implemented  for  those  applications  closed  to 
AFTOMS.  NIST  is  creating  software  gateways  which  will  allow  these  ISO 
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application  protocols  to  interoperate  with  hosts  running  existing  DoD  proto¬ 
cols.  In  all  cases,  it  is  recommended  that  communications  equipment  and  pro¬ 
tocols  selected  for  AFTOMS  be  based  on  ULANA I  and  D  for  LANS  and  the 
DDN  and  LHTTA  for  long  haul.  This  will  insure  compatibility  with  future 
equipment  and  network  upgrades. 

Prepare  base  facility  site  plans.  All  AFTOMS  sites  need  to  be  closely  moni¬ 
tored  for  current  and  planned  base  network  upgrades.  Planning  and  delivery  of 
AFTOMS  systems  must  be  synchronized  with  this  schedule.  Equipment  selec¬ 
tion  should  be  compatible  with  picnned  enhancements  at  the  base. 

Create  software  development  specifications.  All  new  software  required  for 
AFTOMS  should  expect  TCP/IP  or  TP4TP  services  as  a  common  communica¬ 
tions  protocol  baseline.  Utilization  of  NFS  in  addition  to  the  rest  of  the  DoD 
suite  is  highly  recommended  for  transparent  file  transfer  amongst  heteroge¬ 
neous  systems. 
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SECTION  B5: 

Interface  to  Other  Air  Force  Functions! Systems 


B5.1  SCOPE  AND  RELEVANCE 


The  Air  Force  CALS  initiative  began  in  late  1985  in  response  to  a  directive  from  the  Office  of 
the  Secretary  of  Defense  (OSD).  The  directive  called  for  a  long-overdue  modernization  of 
logistics  systems  and  related  processes.  Automation  was  viewed  as  the  major  strategic  ap¬ 
proach  to  accomplish  the  modernization.  Implementing  the  necessary  level  of  automation  is 
a  task  that  intersects  almost  all  of  the  commands,  every  weapon  system  program  in  existence, 
countless  acquisition  and  support  groups,  and  the  entire  contractor  sector. 

Automation  in  the  logistics  world  did  not  just  start  as  a  result  of  this  directive  and  it  will  not 
end  when  the  stated  modernization  goal  is  reached.  Many  systems  were  already  in  the  process 
of  being  acquired  and  deployed  when  the  CALS  initiative  gathered  momentum.  Future  sys¬ 
tems  will  come  on-line  that  will  further  improve  the  logistics  process  for  existing  and  emerg¬ 
ing  weapons  programs.  There  will  always  be  new  and  enhanced  systems  coming  on-line,  and 
the  long-range  goal  of  CALS  is  that  they  all  interoperate. 

However,  this  automation  goal  is  easier  to  state  than  to  achieve.  Interoperability  must  be 
carefully  planned  if  it  is  to  be  realized  operationally.  This  is  extremely  difficult,  even  if  the 
clean  sheet  of  paper  approach  is  used  to  establish  the  best  approach  to  automation.  When  the 
added  constraints  of  reusing  existing  assets  and  retrofitting  current  or  emerging  systems  are 
imposed,  it  becomes  a  monumental  long-term  task.  However,  it  is  not  an  impossible  task. 

AFTOMS  is  a  system  that  was  initiated  after  the  CALS  directive.  In  fact,  AFTOMS  is  the  first 
program  commissioned  as  a  direct  result  of  the  CALS  initiative;  and  it  is  important  to  the 
CALS  initiative  that  AFTOMS  succeed.  Therefore,  the  needs  and  risks  associated  with  inte¬ 
grating  AFTOMS  into  the  Air  Force  logistics  environment  must  be  assessed  and  timely  ac¬ 
tions  taken  to  maximize  AFTOMS’  value  to  the  Air  Force. 

B5.1.1  Existing  Systems 

The  Logistics  Management  of  Technical  Order  System  (LMTOS)  and  Automated  Technical 
Order  System  (ATOS)  are  two  existing  systems  that  currently  perform  some  automation  of 
TO  functions.  This  subsection  briefly  describes  their  current  role  and  identifies  their  changed 
role  once  AFTOMS  is  deployed. 

B5.1.1.1  LMTOS 

LMTOS  has  served  as  the  management  system  for  TOs  for  the  past  twenty  years.  LMTOS 
consists  of  six  subsystems  that  not  only  provide  the  processing  support  for  controlling  auto¬ 
matic  distribution  of  TOs  and  TO  updates  to  the  user  community,  but  also  provide  several 
TO  management  information  reports.  Input  and  output  is  predominantly  via  a  batch-proces¬ 
sing  operation;  therefore,  provisions  for  user  interaction  with  the  system  are  limited.  Output 
products,  which  are  printed  and  distributed  as  paper  copy,  include  management  reports, 
forms,  mailing  labels,  and  error  information. 
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The  system  is  limited  in  its  functionality,  severely  overloaded,  outdated,  and  is  extremely  diffi¬ 
cult  to  support  due  to  a  lack  of  up-to-date  documentation  and  the  fact  that  very  fewprogram- 
mers  are  familiar  with  the  software.  Given  these  LMTOS  problems  and  the  fact  that  the 
LMTOS  management  functions  will  be  an  integral  part  of  AFTGMS,  the  clear  decision  is  that 
AFTOMS  should  undertake  an  aggressive  schedule  of  replacing  the  LMTOS  system  by  FY93 
(corresponding  to  the  AFTOMS  IOC  timetable).  By  FY93  or  soon  after,  LMTOS  will  cease 
operations  and  its  interface  to  AFTOMS  will  not  need  to  be  considered.  The  data  resident  in 
LMTOS  for  managing  paper  TOs  (whether  or  not  they  stay  in  paper  format  permanently  or 
are  convened  to  digital  form)  will  be  imponed  and  consolidated  into  AFTOMS;  thereafter, 
AFTOMS  will  manage  these  TOs.  An  automated  approach  (i.e.  utility  program/module)  will 
be  developed  as  part  of  the  AFTOMS  program  to  acquire,  create,  reformat,  and  load  the  nec¬ 
essary  and  sufficient  data  structures  in  the  AFTOMS  system. 

B5.1.1.2  ATOS 

ATOS  is  essentially  an  organic  publication  system  for  the  production  of  change  pages  to  paper 
TOs.  The  ATOS  system  has  been  deployed  at  the  five  ALCs  and  AGMC  since  the  mid-1980s. 
When  changes  to  existing  TOs  are  approved,  ATOS  generates  digital  text  and  graphics  from 
the  original  page  masters  using  a  combination  of  conversion  and/or  rekeying.  Changes  to 
these  pages  can  be  made  digitally  on  the  system  and  page  masters  can  be  output  from  the 
system.  These  page  masters  are  then  printed  and  delivered  to  the  user  community. 

When  AFTOMS  is  initially  deployed,  the  ATOS  system  will  be  approximately  ten  years  old 
and  at  least  two  technology  generations  behind  current  capabilities.  It  can  be  seen  as  another 
-system  whose  functionality  will  be  displaced  by  AFTOMS.  If  possible,  it  would  make  sense  to 
phase  out  ATOS  during  the  initial  deployment  of  AFTOMS.  At  the  very  least,  ATOS  should 
become  a  subsystem  of  AFTOMS  with  usage  restricted  to  forever-paper  TOs.  For  interoper¬ 
ability  purposes,  ATOS  will  not  be  considered  a  system  that  must  interoperate  intimately  with 
AFTOMS,  except  that  AFTOMS  will  provide  the  management  function  for  work  allocated  to 
ATOS. 

B5.1.2  AFTOMS  Role 

AFTOMS  has  been  designated  as  the  all-inclusive  TO  management  system  for  the  Air  Force. 
In  short,  this  means  that  all  TOs  in  the  Ar  Force  inventory  (existing  and  new)  will  eventually 
fall  under  the  management  responsibility  of  AFTOMS.  Management  consists  of  several  func¬ 
tions  (acquisition,  cataloging/archiving,  distribution,  and  change  management),  all  of  which 
must  be  adequately  supported  by  AFTOMS. 

B5.1.2.1  Near  Term 

AFTOMS  is  scheduled  to  be  deployed  in  the  FY93-FY95  time  frame.  When  deployment 
occurs,  the  big  challenge  will  be  how  quickly  and  smoothly  can  the  transition  to  digital  opera¬ 
tions  occur.  This  section  addresses  the  following  issues: 
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•  New  weapon  programs  coming  on-line  in  this  time  frame; 

•  Assimilation  of  management  responsibility  on  a  system-by-system  basis  from 
LMTOS  (G022);  and 

•  Conversion  efforts  on  a  weapon  system-by-weapon  system  basis. 

At  a  polity- level,  the  CALS  directive  by  Deputy  Secretary  of  Defen;  ?  Taft  states  that  all  weap¬ 
ons  programs  coming  on-line  after  1990  will  deliver  TOs  to  the  Air  Force  in  digital  form. 
These  new  TOs  will  immediately  come  under  the  management  direction  of  AFTOMS.  This 
situation  is  straightforward  since  these  programs  were  never  involved  with  any  other  existing 
systems.  In  this  time  frame,  there  will  only  be  a  few  new  programs  coming  on-line. 

Other  situations  require  synchronization  of  activities.  If  existing  technical  orders  on  a  pro¬ 
gram  remain  forever  paper  but  AFTOMS  assumes  management  responsibility-  from  LMTOS. 
a  need  exists  for  future  production  of  change  pages.  Perhaps,  the  ATOS  system  (as  a  subsys¬ 
tem  to  AFTOMS)  could  continue  to  perform  this  function. 

Another  situation  that  could  occur  is  when  existing  paper  TOs  for  a  weapon  system  are  con¬ 
vened  to  digital  form  (see  Section  B2.3  for  details).  Once  the  conversion  is  completed,  all 
management  functions  become  the  responsibility-  of  AFTOMS. 

In  its  first  few  years  of  deployment,  AFTOMS  will  have  partial  management  responsibility  for 
the  TO  inventory.  All  LMTOS  management  information  should  be  assimilated  at  initial  de¬ 
ployment.  Depending  on  the  strategy  and  pace  of  conversion,  more  and  more  TOs  will  be 
archived  in  AFTOMS  each  year.  How-ever,  from  the  mid-1990s  to  the  year  2000,  AFTOMS 
will  not  have  full  functional  responsibility  for  the  complete  Air  Force  inventory. 

B5.1.2.2  Long  Term 

After  AFTOMS  has  been  operational  for  several  years,  it  should  attain  the  all-inclusive  TO 
management  objective.  By  that  time,  there  should  be  no  traces  of  prior  TO  systems  and  man¬ 
agement  techniques. 

B5.2  STATE  OF  INTEGRATION  FEASIBILITY 
B5.2.1  Interoperability  (Interface  vs.  Integrate) 

For  TOs,  as  well  as  for  all  aspects  of  CALS,  there  is  a  strong  desire  to  end  up  with  an  inte¬ 
grated  solution.  However,  as  TO  automation  is  worked  on,  it  is  evident  that  achieving  full 
integration  requires  a  major  effort,  and  that  full  integration  may  not  be  possible  given  the 
constraints  of  time,  money,  parallel  development,  etc.  The  question  that  remains  is  what  can 
be  accomplished  realistically  in  the  area  of  TOs? 

CALS  has  a  two-phase  strategy;  Phase  1  focuses  on  interfacing  systems  through  the  mid- 
1990s,  while  Phase  2  focuses  on  integrating  systems  over  the  long  term.  The  outlook  for  TOs 
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in  the  Air  Force  is  similar.  At  a  high  level,  the  TO  process  is  shown  in  FIGURE  B5-1  as 
Creation,  Management,  and  Use. 


I 


FIGURE  B5-1.  TECHNICAL  ORDER  FUNCTIONAL  FLOW 

The  process  flows  from  top  to  bottom  with  some  feedback  loops.  The  Creation  process  takes 
place  primarily  within  the  contractor  sector  by  producers.  TOs  are  delivered  by  contractors  to 
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the  ALCs  where  the  Management  functions  occur.  Technical  orders  are  delivered  by  AF- 
TOMS  to  the  users  at  base  level  and  below  where  the  user  functions  occur. 

The  long-term  goal  of  the  Air  Force  and  AFTOMS  is  to  have  interoperability  across  all  TO 
functions.  This  is  commonly  called  vertical  integration.  For  initial  deployment  a  realistic  strat¬ 
egy’  for  the  Air  Force  is  to  have  vertical  interoperability.  Since  there  are  many  producer  sys¬ 
tems  that  could  provide  input  to  AFTOMS  and  many  user  systems  that  AFTOMS  would  de¬ 
liver  to,  well-defined  standard  interfaces  are  needed  at  these  in-and-out  points  to  achieve 
interoperability. 

B5.2.2  Assumptions 

The  feasible  interoperability  approaches  are  based  on  the  following  assumptions: 

•  In  the  FY93-FY95  deployment  time  frame,  interfacing  will  be  the  main  form  of 
interoperability’; 

•  An  automated  technical  order  solution  is  a  near-term  goal,  while  an  auto¬ 
mated  technical  information  solution  (comprising  TOs,  product  data,  logistics 
support  data,  software  product  data,  etc.)  is  a  long-term  goal; 

•  The  above  goals  can  be  achieved  incrementally’; 

•  There  will  be  standardized  interfaces  on  the  both  the  input  and  output  sides  of 
AFTOMS;  and 

•  LMTOS  and  ATOS  will  not  be  a  part  of  the  automated  TO  solution  of  the  late 
1990s. 

B5.3  PARTICULAR  INTEGRATION  APPROACHES 
B5.3.1  Input  to  AFTOMS 

This  subsection  describes  systems  that  deliver  TOs  (and  related  information)  to  AFTOMS.  In 
FIGURE  B5-1,  they  are  depicted  by  arrows  that  enter  the  AFTOMS  TOMA/TOC  function¬ 
al  box.  There  are  two  types  of  systems: 

•  Authoring  (producer)  systems;  and 

•  Conversion  systems. 

B5.3.1.1  Authoring  Systems 

TO  authoring  takes  place  primarily  in  the  contractor  sector.  Many  different  kinds  of  systems 
are  used;  most  of  these  systems  are  not  under  the  control  of  the  Air  Force.  Furthermore,  it 
would  be  unwieldy  to  define  an  interface  catering  to  the  details  of  very  different  and  modifi¬ 
able  producer  configurations.  To  bring  some  consistency  and  order  to  this  interchange,  the 
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Air  Force  (and  DoD)  recognize  the  need  for  a  standard  interface.  This  interface  should  not 
require  any  detailed  knowledge  by  AFTOMS  of  the  hardware/software/communications 
configurations  used  by  contractors  in  their  authoring  systems.  Also,  AFTOMS  should  not  be 
dependent  on  the  embedded  functionality  of  any  authoring  system. 

Interoperability  of  AFTOMS  with  authoring  systems  will  be  at  the  data  interchange  level. 
The  implementation  vehicle  to  accomplish  this  interchange  is  the  MIL-STD  1840  and  the 
conformance  software  packages  resident  in  the  authoring  systems  and  in  AFTOMS.  This 
MIL-STD  1840-based  approach  has  been  widely  accepted  in  the  CALS  community  by  the 
major  participants  and  is  the  only  authorized  approach  for  the  near  term  (CALS  Phase  1).  In 
the  long  term  (CALS  Phase  2),  other  more  integrated  approaches,  now  under  discussion  by 
various  committees,  could  be  defined  and  adopted. 

B5.3.1.2  Conversion  Systems 

The  primary’  role  of  conversion  systems  is  to  convert  paper  TOs  into  digital  form.  There  are 
approximately  the  same  number  of  conversion  systems  in  existence  as  there  are  authoring 
systems.  Compared  to  authoring  systems,  technical  solutions  for  conversion  systems  are  not 
fully  developed  as  operational  systems.  Conversion  could  take  place  organically  within  the 
A'r  Force,  at  service  bureaus,  or  in  the  contractor  sector.  Regardless  of  where  the  process 
takes  place,  the  many-to-one  mapping  still  exists. 

Conversion  is  not  a  totally  automated  process.  There  is  still  a  considerable  amount  of  trained 
judgment  and  labor  required  to  clean  up  and  complete  the  processing.  Over  the. next  few 
years,  the  average  amount  of  trained  labor  tequired  per  scanned  page  will  be  significantly 
reduced.  In  the  near  term  the  best  way  to  achieve  interoperability  between  conversion  sys¬ 
tems  and  AFTOMS  is  to  specify  an  interface  that: 

•  Is  standard  at  the  data  interchange  level; 

•  Does  not  depend  on  the  degree  of  trained  labor  in  the  conversion  process;  and 

•  Is  similar  to  the  authoring  system  interface. 

If  the  conversion  output  interface  is  equivalent  to  the  authoring  system  interface,  it  would  be 
transparent  to  AFTOMS  where  the  TOs  came  from;  and  all  subsequent  management  func¬ 
tions  could  be  performed  identically  on  all  imported  TOs.  This  would  simplify  interoperabil¬ 
ity  on  the  AFTOMS  side.  Just  as  authoring  systems  need  to  acquire  MIL-STD  1840  support 
software,  so  will  conversion  systems.  The  combination  of  conversion  functionality,  trained 
labor,  and  MIL-STD  1840  support  on  the  conversion  system  side  of  the  interface  will  produce 
incoming  TO  data  in  the  standard  acceptable  format.  AFTOMS  will  not  need  to  readjust  its 
activity  every  time  there  are  conversion  technology  advances.  In  addition,  this  same  interface 
could  remain  in  place  as  long  as  conversion  activity  is  still  required. 
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B5.3.2  User  (Deliver})  Systems 


As  shown  in  FIGURE  B5-1,  AFTOMS  resides  in  the  middle  of  the  overall  TO  process.  To 
complete  vertical  integration  of  the  process,  AFTOMS  must  deliver  the  technical  orders 
(along  with  some  related  management  information)  to  users.  In  FIGURE  B5-1,  the  point  of 
interoperability  is  shown  as  the  dotted  line  separating  the  Base  CTODO  (inside  the  domain  of 
AFTOMS)  from  the  Distribution  box,  which  links  user  systems  at  the  base  level. 

One  way  in  which  TOs  can  flow  to  users  is  by  using  AFTOMS  demand  printing  at  the  Base 
CTODO  and  intra-base  delivery.  This  subsection  describes  the  more  sophisticated  tech¬ 
nique  of  digital  delivery  to  other  systems  at  base  level.  These  other  systems  will  assume  the 
responsibility  of  delivering  the  TOs  (in  paper  or  display  form)  to  the  users.  These  end-user 
delivery  systems  are  an  integral  part  of  the  vertical  integration  of  TOs,  but  are  not  part  of  the 
current  AFTOMS  system.  If  no  User  System  exists  below  the  CTODO,  then  the  paper  deliv¬ 
ery  approach  will  be  used. 

B5.3.2.1  Standard  Interface 

Like  the  input  systems  described  in  Section  B5.3.1,  many  user  systems  will  exist.  Currently, 
there  is  an  initiative  to  define,  acquire,  and  deploy  a  standard  base-level  user  system  that  can 
be  adopted  by  many  weapon  system  programs.  However,  this  initiative  is  at  a  very  formative 
stage  and  will  not  become  reality  before  the  year  2000.  Consequently,  w’hen  AFTOMS  is 
initially  deployed,  the  one-to-many  relationship  between  AFTOMS  and  user  syste ms  will  ex¬ 
ist. 

Considering  all  the  specific  user  system  configurations  and  functionalities  that  AFTOMS 
might  be  called  on  to  distribute  TOs  to  or  otherwise  support,  a  standard  interface  is  the  most 
appropriate  approach  for  interoperability.  However,  there  is  more  than  a  one-way  flow  of 
information  that  must  be  supported.  There  are  three  major  information  flows: 

•  Technical  Orders  (AFTOMS  #  user  system); 

•  Profile  Registration  (user  system  $  AFTOMS);  and 

•  Change  Requests  (user  system  f  AFTOMS) 

Two  new  weapon  system  programs  under  development,  the  B2  and  the  ATF,  are  planning  to 
deploy  user  systems  at  their  operating  bases.  The  B2  will  be  using  the  Improved  Technical 
Data  System  (ITDS)  and  the  ATF  is  planning  to  develop  a  user  system  based  on  the  Integrated 
Maintenance  Information  System  (IMIS)  concept.  While  these  user  systems  are  currently 
program-specific,  they  could  be  modified  to  become  solutions  for  other  programs.  Since 
these  efforts  are  well  underway,  a  more  detailed  look  at  their  interfaces  with  AFTOMS  is 
needed  to  integrate  the  operating  concepts  and  system  configurations  on  both  sides  of  the 
interface. 
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B5.3.2.2  ITDS 


ITDS  is  a  user  system, -residing  at  operating  bases  and  depots,  which  delivers  TOs  and  asso¬ 
ciated  data  to  maintenance  and  support  users.  The  ITDS  configuration  is  shown  in 
FIGURE  B5-2.  A  key  component  in  the  configuration  is  the  Local  Library.  A  Local  Library’, 
one  per  installation,  serves  as  the  data  base  manager  and  repository  for  the  TOs  at  that  instal¬ 
lation.  It  is  linked  to  the  shops  and  flight  line  devices  via  LAN. 


FIGURE  B5-2.  ITDS  CONFIGURATION  (CONCEPTUAL  VIEW') 

The  AFTOMS  concept  provides  a  CTODO  at  every  base  and  depot  that  it  services.  The  AF- 
TOMS  CTODO  and  the  ITDS  Local  Library  need  to  be  linked,  using  logical  gateways  for 
their  respective  systems,  as  shown  in  FIGURE  B5-3.  This  interface  would  support  the  infor¬ 
mation  flows  identified  above  and  would  not  require  either  system  to  deal  with  the  configura¬ 
tion  and  technical  details  of  the  other  system.  Furthermore,  if  the  configuration  of  either  sys- 
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tem  was  modified,  it  would  probably  not  affect  this  interface.  Since  both  systems  will  be  under 
development  during  the  same  time  period,  this  is  an  important  consideration. 


B5.3.2.3  IMIS 

When  implemented,  IMIS  will  be  based  on  a  maintenance  information  delivery  concept  that 
is  designed  to  improve  the  capabilities  of  aircraft  maintenance  organizations.  Technicians  will 
be  provided  with  a  single  information  system  for  intermediate  and  organizational  mainte¬ 
nance.  IMIS  will  reside  at  base  level  and  will  provide  the  technician  with  direct  access  to  sev¬ 
eral  maintenance  information  systems  and  databases.  IMIS  will  display  graphical  technical 
instructions  (i.e.  Type  C  TO  data),  provide  intelligent  diagnostic  advice,  provide  aircraft 
battle  damage  assessment  aids,  analyze  in-flight  performance  and  failure  data,  analyze  air¬ 
craft  historical  data,  access  and  interrogate  on-board  built-in-test  capabilities.  It  will  also 
provide  the  technician  with  easy,  efficient  methods  to  receive  work  orders,  report  mainte¬ 
nance  actions,  order  parts  from  supply,  and  complete  computer-aided  training  lessons  and 
simulations. 

The  IMIS  concept  is  illustrated  in  FIGURE  B5-4.  TOs  are  one  of  the  key  information  types 
that  need  to  be  delivered  to  IMIS.  Therefore,  the  AFTOMS-LMIS  interface  requirements 
are  very  similar  to  the  AFTOMS-ITDS  ones.  A  major  difference  exists  in  what  IMIS  does 
with  various  information  types  prior  to  its  delivery  to  system  maintenance  users.  First,  a  sig- 
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nificant  amount  of  integration  with  other  data  types  (diagnostics,  training,  etc.)  needs  to  oc 
cur.  Then,  the  linked  information  is  presented  to  users  in  a  more  integrated  manner  as  de 
scribed  above.  AFTOMS  needs  to  provide  a  TO  interface  as  shown  in  FIGURE  B5-5. 


FIGURE  B5-4.  IMIS  INTEGRATION  OF  DATA 


FIGURE  B5-5.  AFTOMS-IMIS  INTERFACE 
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In  fact,  all  user  systems  will  have  different  functional  capabilities,  data  types,  etc.  This  illus¬ 
trates  why  AFTOMS  needs  to  develop  a  standard  Tier  3-Tier  4  interface  and  not  be  too  tight¬ 
ly  coupled  to  user  systems  to  which  it  delivers  TOs. 

B5.3.2.4  Layered  Interface 

The  interface  to  user  systems  such  as  ITDS  and  IMIS  will  have  a  layered  look,  as  illustrated  in 
FIGURE  B5-6.  On  the  AFTOMS  side  will  be  the  standard  portion  of  the  interface.  On  the 
user  system  side,  each  system  will  develop  a  tailored  module  to  complete  the  link  up. 


Standard  User  System  Interface 

AFTOMS  SIDE 

ITDS 

IMIS 

Other  (Future) 

USER  SYSTEM  SIDE 

FIGURE  B5-6.  USER  SYSTEM  INTERFACE 

B5.3.3  Other  Systems 

The  IMIS  system  introduces  the  concept  of  horizontal  integration  to  TOs.  Horizontal  integra¬ 
tion  is  the  integration  of  data,  functions,  systems,  etc.  within  an  organizational  boundary  (i.e. 
base-level  maintenance).  FIGURE  B5-4  shows  the  different  types  of  data  that  are  usually- 
used  to  perform  maintenance  activities.  Similar  situations  exist  in  the  engineering  design  and 
manufacturing  areas.  Two  systems:  Core  Automated  Maintenance  System  (CAMS) 
(deployed)  and  PDD  (concept),  fit  into  this  category  and  warrant  a  closer  look  for  interoper¬ 
ability  with  AFTOMS. 

B5.3.3.1  CAMS 

CAMS  is  a  standard  base-level  system  for  maintenance  data  collection  and  maintenance 
management  information  and  control.  It  is  a  transaction  processing  system  that  supports 
base-level  maintenance  for  aircraft,  ground-launched  cruise  missiles,  engines,  trainers,  sup¬ 
port  equipment,  test  equipment,  missiles,  munitions,  and  communications  electronics. 
CAMS  also  inputs  job  data  and  outputs  information  to  personnel  at  remote  locations  in  the 
maintenance  complex. 
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Systems  like  ITDS  and  IMIS  will  exist  at  base  level.  CAMS  currently  exists  at  many  bases  and 
performs  maintenance  functions.  How  should  AFTOMS  interoperate  with  CAMS? 

In  FIGURE  B5-4  TOs  (AFTOMS)  are  linked  with  LMIS  and  Historical  Data  Collection 
(CAMS)  is  linked  with  IMIS.  In  the  presence  of  an  integrating  system  at  base  level  such  as 
IMIS,  AFTOMS  would  not  need  to  link  directly  with  CAMS.  CAMS  is  not  a  system  that  plays 
a  direct  role  in  the  vertical  integration  of  TOs;  thereby,  the  linkage  is  indirect.  However,  if 
there  is  not  an  integrating  system  at  base  level  and  there  is  a  need  for  TO  data  to  be  delivered 
directly  to  CAMS,  the  standard  interface  approach  can  be  implemented  for  CAMS  as  well. 

B5.3.3.2  Product  Definition  Data  (PDD)  System  Concept 

The  PDD  concept  is  depicted  in  FIGURE  B5-7. 


The  PDD  concept  has  two  major  components:  a  Product  Information  Management  (PIM) 
system,  and  the  distribution  system  (that  maps  to  the  AFTOMS  distribution  system).  PIM 
provides  accurate  and  consistent  data  to  the  users  of  PDD  by  managing  the  access,  storage, 
and  change  of  the  diverse  types  of  PDD  data  (raster,  vector,  manufacturing  data,  specifica¬ 
tions,  etc.).  PIM  has  three  primary  functions: 

•  Data  Management  -  This  function  assigns  descriptors  that  give  each  PDD 
component  identifying  information  for  later  retrieval  and  cross-referencing 
with  all  other  related  PDD  components.  The  Data  Management  system  will 
access  the  PDD  data  in  an  integrated  fashion. 

•  Configuration  Change  Management  -  This  function  makes  use  of  this  irte 
grated  PIM  database  during  implementation  of  a  change  to  an  existing  configu¬ 
ration  item.  All  other  affected  data  types  that  need  to  be  changed  are  found  vi  a 
cross-referencing  information  and  are  updated  to  reflect  the  item  change.  Or  e 
of  these  inter-dependent  data  types  is  TOs. 

•  Data  Usage  -  This  function  records  PDD  data  creation  and  use.  This  informa¬ 
tion  will  be  used  to  focus  future  PDD  data  acquisitions  and  provide  a  monitor¬ 
ing  of  the  operational  capability. 

PDD  is  currently  a  concept  and  the  major  use  of  the  AFTOMS-PDD  interface  would  be  for 
support  of  the  ALC  sustaining  engineering  functions  (modifications  repair,  etc.).  Because  of 
the  close  relationship  between  engineering  design  changes  and  corresponding  upda«.“s  in 
TOs.  it  is  important  to  link  these  data  bases  via  another  standard  CALS  interface. 

B5.4  RISK  ASSESSMENT 

AFTOMS  is  a  system  that  will  be  deployed  in  the  F93-FY95  time  frame.  Systems  such  as 
ITDS,  IMIS,  and  PDD  have  acquisition  and  deployment  plans  that  overlap  this  time  frame. 
Currently,  these  systems  are  all  at  the  conceptual  level  and  are  more  or  less  moving  targets. 
Often,  good  ideas  at  the  conceptual  level  are  not  that  easy  to  implement  and  do  not  solidify 
until  a  workable  detail  design  is  produced.  The  timing  is  such  that  these  programs  will  not 
reach  a  detail  design  level  for  several  years.  The  risk  that  these  systems  will  not  interoperate 
remains  high  until  more  details  are  worked  out  in  defining  the  standard  interfaces. 

CALS  is  an  initiative  that  stresses  interoperability.  There  is  always  a  tendency  in  large  efforts 
to  try'  to  acquire  as  much  capability  as  soon  as  possible.  Since  /  JFTOMS  is  the  first  of  the 
CALS  initiatives,  an  inherent  risk  exists  that  the  Air  Force  or  DoD  will  try  to  turn  AFTOMS 
into  CALS.  CALS  goals  need  to  be  realized  incrementally.  AFTOMS,  as  currently  scoped, 
is  a  first  and  very  significant  step  for  CALS.  To  avoid  adding  risk,  the  Air  Force  must  stabilize 
and  maintain  the  scope  of  AFTOMS,  and  clearly  identify  the  standard  interfaces  to  other 
CALS  systems. 
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B5.5  RISK  ABATEMENT 

To  reduce  risk  for  timely  deployment  of  AFTOMS  and  its  interoperability  with  other  CALS 
systems  when  they  are  deployed,  the  following  activities  should  take  place  in  the  FY90-FY91 
time  frame: 


•  Work  with  all  participating  organizations  to  solidify  the  MIL-STD  1840  inter¬ 
face  for  acceptance  of  technical  order  data  into  AFTOMS; 

•  Develop  a  standard  interface  specification  for  user  systems  as  soon  as  possible: 

•  Form  a  ream,  consisting  of  AFTOMS  and  ITDS  personnel,  to  define  in  detail 
the  AFTOMS-1TDS  interface;  and 

•  Form  a  team,  consisting  of  AFTOMS  and  IMIS  personnel,  to  define  in  detail 
the  AFTOMS-IMIS  interface. 


B5-14 


SECTION  B6: 
System  Buildability 


B6.1  SCOPE  AND  RELEVANCE 

The  success  of  AFTOMS  is  predicated  both  on  building  a  high  quality  system  that  conforms  to 
the  Request  For  Proposal  (RFP)  and  then  embedding  it  operationally  into  the  AFLC  organi¬ 
zational  structure  and  culture  so  that  it  properly  services  the  Air  Force  Using  Commands.  A 
poor  quality  system  will  not  survive  operationally,  or  will  limp  along  at  a  substandard  level  of 
productivity,  and  certainly  will  not  provide  a  solid  technical  order  component  for  future 
CALS  integration  projects.  On  the  other  hand,  a  system  that  is  not  operationally  accepted  by 
either  AFLC  or  the  using  commands  -no  matter  how  good  its  technical  and  other  merits- 
must  also  be  considered  a  failure. 

The  organizational  issues  (which  essential!}  map  AFTOMS  functionality  and  responsibility 
to  existing  or  new  organizational  elements,  or  which  develop  RFP  requirements  to  prevent 
any  such  conflicts  from  arising)  were  considered  to  be  outside  the  scope  of  the  AFTOMS  POC 
effort  and  are  being  addressed  by  the  AFTOMS  SPO.  However,  the  POC  team  recognized 
that  proper  design  and  training  approaches  could  help  mitigate  the  organizational  acceptance 
risk  almost  independently  of  the  actual  organizational  mapping.  Beyond  that,  the  risks  re¬ 
lated  to  organizational  issues  will  not  be  considered  further  in  this  section,  which  will  now 
focus  on  system  buildability  issues. 

System  buildability  addresses  the  integration  of  individual  dimensions  and  technologies  to 
the  task  of  building  a  high-quality  system  that  fully  realizes  the  RFP.  Since  the  RFP  is  not  yet 
available,  the  To-Be  Model  was  used  as  a  partial  surrogate  for  it.  Aspects  of  system  quality 
are  discussed  in  Section  B8  (Operational  Utility)  so  they  will  not  be  addressed  directly  in  this 
section;  however,  the  evaluation  of  buildability  risk  indirectly  presumes  high,  but  not  exces¬ 
sively  high,  quality  goals  for  AFTOMS. 

Within  the  foregoing  context,  system  buildability  can  be  assessed  by  developing  a  framework 
for  modeling  the  project  risk,  evaluating  the  overall  risk,  identifying  the  risk  contributors,  and 
finding  opportunities  for  risk  reduction.  To  facilitate  AFTOMS  system  buildability,  it  is  criti¬ 
cal  that  the  project  risk  be  kept  low  overall,  maybe  medium  in  few  carefully-managed  areas 
where  it  can’t  or  shouldn’t  be  reduced  further,  and  never  above  medium  in  any  area;  the  latter 
would  jeopardize  the  project.  The  choice  of  actual  technologies  or  methods  of  integration 
used  is  constrained  by  the  other  needs  of  AFTOMS  (e.g.,  functionality,  standards  confor¬ 
mance,  contribution  to  system  quality,  etc.),  but  within  those  constraints  each  choice  maybe 
traded  off  to  reduce  project  risk. 

B6.2  STATE  OF  INTEGRATION  FEASIBILITY 

To  assess  the  feasibility  of  building  AFTOMS,  a  framework  for  quantitatively  modeling  proj¬ 
ect  risk  must  be  developed.  One  useful  and  not  overly  complex  analytical  approach  is  to  de¬ 
compose  the  total  project  risk  into  a  set  of  contributing  risk  factors,  assess  and  weight  both  the 
importance  and  risk  contribution  of  each  such  factor,  and  finally  consolidate  all  these 
weighted  contributions  into  an  integrated  whole.  Using  this  model  to  provide  a  baseline  ref- 
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erence,  the  project  risk  can  be  evaluated  first  as  if  no  POC  work  had  been  done.  Then,  it  can 
be  reevaluated  using  the  findings  from  the  POC.  The  resulting  changes  in  total  project  risk 
and  the  individual  risk  contributors  highlight  areas  of  significant  post-POC  residual  risk, 
areas  where  risk  reductions  were  attained  readily  or  with  difficulty,  and  thereby  disclose  op¬ 
portunities  for  further  risk  reduction  work  if  needed. 

B6.2.1  Risk  Decomposition 

A  hierarchical  decomposition  of  total  AFTOMS  buildability  risk  is  shown  in  FIGURE  B6-1. 
Hierarchical  decomposition  is  used  because  it  provides  a  simple,  familiar  structure  for  me¬ 
thodically  decomposing  risk  into  components,  then  recursively  decomposing  each  of  those 
risk  components,  etc.,  as  detailed  and  deep  as  needed;  it  offers  two  other  major  advantages: 
the  level  of  detail  in  the  decomposition  can  vary  in  different  parts  of  the  structure  depending 
on  what  makes  sense  for  a  risk  component;  and  nearby  risk  factors  at  the  same  level  within  a 
risk  component  can  be  traded  off  against  their  neighbors  or  modified  to  reduce  the  total  local 
risk  contribution  of  their  parent  component  without  significantly  increasing  the  risk  of  more 
remote  components.  A  small  practical  disadvantage  of  this  structured  decoupling  is  that 
weighting  factors  have  to  be  developed  for  each  risk  contributor  so  that  they  all  can  be  recom¬ 
bined  into  the  whole  project  buildability  risk. 

Following  this  risk  decomposition  approach,  the  total  AFTOMS  Buildability  Risk  is  decom¬ 
posed  at  the  first  level  into  the  following  four  component  risks: 

•  Task  Risk;  Captures  the  risks  associated  with  WHAT  is  being  built; 

•  Technologies  and  Tools  Risk:  Captures  the  risks  associated  with  HOW  it  will  be 
built; 

•  Project  Resources  Risk:  Captures  the  risks  associated  with  the  real-world 
CONSTRAINTS  within  which  it  has  to  be  built;  and 

•  Team  Risk:  Captures  the  risks  associated  with  the  various  TEAMS  involved  in 
the  building  process. 

Continuing  with  the  FIGURE  B6-1  risk  decomposition  to  the  next  lower  level,  column-by¬ 
column,  first  consider  the  Task  Risk. 

B6.2.1.1  Task  Risk  Decomposition 

The  Task  Risk  is  composed  of  the  following  two  component  risks: 

•  System  Complexity  Risk:  Captures  the  risks  associated  with  the  INHERENT 
complexity  of  WHAT  is  to  be  built;  and 

•  Requirements  Specification  Risk:  Captures  the  risks  associated  with  the 
QUALITY  of  the  DESCRIPTION  of  WHAT  is  to  be  built. 
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FIGURE  B6-1.  WEIGHTED  RTSK  BREAKDOWN  STRUCTURE 


Continuing  to  the  next  level,  each  of  the  above  two  risk  components  is  decomposed  as  fol¬ 
lows.  The  System  Complexity  Risk  is  composed  of  the  following  four  risk  factors: 

•  Large  Software  Size  Risk:  Increases  as  the  amount  of  functionality  and  the  size 
of  the  software  to  be  developed  increases,  but  decreases  (as  in  AFTOMS)  if 
chunks  of  that  functionality  can  be  provided  by  integrating  off-the-shelf  com¬ 
mercial  software  products; 

•  Very  Involved  Integration  Risk:  Increases  as  the  amount  of  functionality,  num¬ 
ber  of  commercial  software  products,  variety  of  hardware  platforms/operating 
systems/development  languages/etc.,  and  interfaces  to  other  systems  have  to 
be  used  or  integrated  in  a  networked,  distributed  environment  to  build  AF¬ 
TOMS; 

•  Tightly  Coupled  Functionality  Risk:  Increases  the  problems  associated  with 
making  local  changes  in  functionality  or  correcting  errors  during  testing  if 
(through  the  design)  effects  of  such  changes  are  not  or  cannot  be  kept  local,  but 
interact  (in  perhaps  intricate  and  subtle  way's)  with  many  logically  remote  parts 
of  the  system;  the  AFTOMS  concept  does  not  require  much  tight  coupling  of 
functionality';  c 

•  State-of-the-Art  Performance  Risk:  Increases  when  the  system  must  break 
through  the  existing  performance  envelope  and  do  things  no  other  system  has 
done  before,  and  where  every  design  tradeoff  favors  increased  performance  at 
the  expense  of  other  desirable  characteristics;  AFTOMS  makes  no  such  ex¬ 
traordinary  performance  demands. 

Similarly,  the  Requirements  Specification  Risk  is  composed  of  the  following  three  risk  fac¬ 
tors: 

•  Newness  or  Unfamiliarity  Risk:  Increases  if  requirements  are  being  developed 
for  functionality,  hardware  platforms,  etc.,  outside  the  past  experience  of  the 
RFP  team  so  in  effect  the  team  is  learning  and  specifying  this  system  or  type  of 
system  for  the  first  time  (AFTOMS’  case); 

•  Unstable,  Ambiguous,  Incomplete  Requirements  Risk:  Increases  when  the 
technical  portion  of  the  RFP  is  loosely  stated  so  that  significant  requirements 
changes  are  required  during  development  to  clarify,  elaborate,  correct,  inte¬ 
grate,  or  tradeoff  initial  RFP  requirements  (representing  a  potential  problem 
in  AFTOMS);  and 

•  Cannot  Allocate,  Measure,  or  Test  Requirements  Risk:  Increases  when  the 
RFP  requirements  are  stated  in  such  vague  or  general  terms  that  they  don’t  dis¬ 
criminate  (in  the  hundreds  of  operationally  important  particulars)  between  a 
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quality  AFTOMS  system  and  a  poor  one;  and  they  don’t  provide  the  validation 
baseline  needed  for  acceptance  testing  of  the  delivered  system  (representing 
another  potential  pioblem  in  AFTOMS). 

B6.2.1.2  Technologies  and  Tools  Risk  Decomposition 

Continuing  to  the  Technologies  and  Tools  Risk  column  of  FIGURE  B6-1,  this  risk  component 
can  be  decomposed  into  the  following  two  major  risk  subcomponents: 

•  Immature  Technologies  Risk:  Captures  the  risks  associated  with  the  hardware 
and  software  technologies  and  products  that  will  be  integrated  into  AFTOMS 
and  have  to  perform  operationally  during  AFTOMS  use;  and 

•  Immature  Development/Support  Tools  Risk:  Captures  the  risks  associated 
with  the  hardware  and  software  tools  used  to  build  AFTOMS,  and  perhaps 
maintain  it,  but  that  will  not  become  part  of  the  operational  system. 

Continuing  to  the  next  level,  each  of  the  above  two  risk  components  is  decomposed  as  fol¬ 
lows.  The  Immature  Technologies  Risk  is  composed  of  the  following  two  risk  factors: 

•  H\V  Functionality  or  Performance  Gap  Risk:  Increases  if  needed  standards- 
compliant  hardware  platforms,  pcnphs. .  communications,  or  other  devices 
cannot  provide  adequate  support  to  AFT  C  S  functionality,  or  adequate  levels 
of  performance,  throughput,  and  rehab.!'  and 

•  SW  Functionality  or  Performance  Gap  Risk:  Increases  if  needed  standards- 
compliant  software  technologies  and  products  cannot  provide  needed 
AFTOMS  functionality,  adequate  levels  of  performance,  or  require  significant 
desigi.  changes  or  workarounds. 

Similarly,  the  Immature  Development/Support  Tools  Risk  is  also  composed  of  the  following 
two  risk  factors: 

•  Not  Available  for  Specific  HW/SW  Environment  Risk:  Increases  if  hardware 
devices  or  software  technology  development/or  tool  products  needed  to  build 
AFTOMS  do  not  either  exist,  support  required  standards,  or  integrate/interop¬ 
erate  well  with  other  system  elements  in  the  HW/SW  development  environ¬ 
ment;  and 

•  Incomplete,  Unstable,  or  Productivity-constraining  Risk:  Increases  if  the  de¬ 
velopment/support  tools  provide  incomplete  functionality,  are  not  well-tested, 
or  are  operationally  difficult  to  use. 
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B6.2.1.3  Project  Resources  Risk  Decomposition 

Continuing  to  the  Project  Resources  Risk  column  of  FIGURE  B6-1,  this  risk  component  can 
be  decomposed  into  the  following  two  major  risk  subcomponents: 

•  Ambitious  Scheduling  Risk:  Captures  the  risks  associated  with  building  and 
fielding  AFTOMS  in  a  compressed  time  frame,  thereby  requiring  technical  in¬ 
tegration  of  many  dynamically  changing  parallel  activities;  and 

•  Response  Flexibility  Risk:  Captures  the  risks  associated  with  quickly  evaluat¬ 
ing  and  resolving  unforeseen  technical  problems  or  taking  advantage  of  techni¬ 
cal  opportunities  while  maintaining  forward  project  momentum  to  keep  to  the 
schedule. 

These  two  risk  components  were  not  decomposed  further  because  such  details  were  beyond 
the  scope  of  this  POC  study,  and  it  was  unnecessary  to  do  so  for  judging  and  quantitatively 
estimating  their  risk  contributions. 

B6.2.1.4  Team  Risk  Decomposition 

Continuing  to  the  Team  Risk  column  of  FIGURE  B6-1,  this  risk  component  can  be  decom¬ 
posed  into  the  following  three  major  risk  subcomponents: 

•  Project  Office  Risk:  Captures  the  risks  associated  with  managing  a  large,  com¬ 
plex,  technologically  advanced  project  under  conditions  of  an  ambitious  sched¬ 
ule,  many  suppliers  of  technology  products  and  services,  and  with  a  team  (SPO, 
Prime  Contractor,  and  IV  &.  V  Contractor)  that  has  not  worked  together  be¬ 
fore  on  a  similar  project; 

•  Prime  Contractor  Risk:  Captures  the  risks  associated  with  defining,  architect¬ 
ing,  designing,  implementing,  integrating,  testing,  documenting,  installing,  and 
managing  a  large-scale,  technologically  advanced  and  complex  hardware/soft¬ 
ware  integration  project  such  as  AFTOMS  that  involves  numerous  hardware 
and  software  product  suppliers  and  subcontractors:  and 

•  IV  &  V  Contractor  Risk:  Captures  the  risks  associated  with  reviewing  and 
evaluating  the  prime  contractor’s  interim  and  final  technical  products  (i.e.,  re¬ 
quirements  clarification,  architecture,  high-level  and  detail-level  designs,  im¬ 
plementation  code,  testing  results,  documentation,  etc.),  validating  the  system 
against  the  approved  requirements,  performing  special  studies  for  the  SPO, 
and  doing  all  this  in  a  timely  fashion  so  as  not  to  jeopardize  the  schedule  and 
ensure  system  quality. 

These  three  risk  components  were  not  decomposed  further  because  such  details  were  beyond 
the  scope  of  this  POC  study,  and  it  was  unnecessary  to  do  so  for  judging  and  quantitatively 
estimating  their  risk  contributions. 
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B6.2.2  Risk  Contribution  Modeling 


Given  the  foregoing  AFTOMS  Buildability  Risk  decomposition,  the  resulting  component 
elements  (or  risk  factors  of  the  decomposition)  must  be  weighted  and  their  relative  risk  con¬ 
tributions  estimated.  A  simple  model  for  doing  this  for  any  risk  factor-X  is  shown  in  FIG¬ 
URE  B6-2. 


FACTOR  -  X 


PRE  -  POC 


A  JUDGMENTAL  MEASURE  OF 
THE  CUMULATIVE  NUMBER  AND 
SIZE  OF  THIS  FACTOR’S  RISK  AR¬ 
EA/HOT  SPOTS  (Le.,  the  extent  of  the 
unknown  areas,  their  integration  com¬ 
plexities,  and  overall  importance  of 
this  factor  iu  11. «•  touti 


•  RISK  (R) : 

A  JUDGMENTAL  MEASURE 
OF  THE  AVERAGE  INTENSITY 
OF  THE  RISK  WITHIN  THAT 
FACTOR. 

•  RISK  CONTRIBUTION  (C) : 
THE  PRODUCT  Wx  R 


FACTOR  -  X 


_ POST  - POC _ 

•  SEE  A  NET  REDUCTION  FOR 
THAT  RISK  FACTOR  IN: 

THE  NUMBER  AND  EXTENT  OF 
HOTSPOTS;  AND 

THEIR  AVERAGE  RESIDUAL 
INTENSITY  OR  RISK 


FIGURE  B6-2.  RISK  JUDGMENT  AND  WEIGHTING 


Consider  first  the  pre-POC  perception  of  the  risk  contribution  of  factor-X.  Intuitively,  this 
risk  contribution  can  be  estimated  as  a  product  of  two  judgmental  measures:  how  widespread 
or  how  much  of  the  AFTOMS  system  does  it  potentially  affect  (captured  as  the  weighting.  W); 
and  how  much  perceived  risk  does  that  factor  potentially  have  (captured  as  the  risk,  R).  Thus, 
with  this  model  it  is  possible  to  have:  a  low-risk  factor  that  is  widespread  which  accumulates 
to  a  moderate  risk  contribution;  or  a  high-risk  factor  that  is  localized  which  results  in  a  mod¬ 
erate  risk  contribution  at  most;  or  a  high-risk  factor  that  is  widespread  which  produces  a  very- 
high  risk  contribution:  or  a  low-risk  factor  that  is  localized  which  contributes  little  risk;  or 
finally,  various  shadings  of  W  and  R  which  result  in  risk  contributions  ranging  from  low  to 
high. 

The  POC  activity  (whether  solely  hands-on,  solely  hands-off,  or  some  combination  of  the 
two)  thinks  through  and  evaluates  either  directly  or  indirectly  that  factor's  role  and  effect  on 
AFTOMS,  and  if  its  risk  contribution  is  significant,  it  suggests  appropriate  risk  abatement 
strategies.  In  this  dual  risk  assessment/abatement  process  some  pre-POC  risk  perceptions 
turn  out  to  be  non-existent  or  insignificant;  whereas,  others  turn  out  to  be  significant,  but  can 
be  avoided,  neutralized,  or  managed  with  some  change  in  strategy  or  design  approach;  while  a 
few  may  turn  out  to  be  unabatable  or  even  more  severe  than  anticipated.  Thus,  the  POC 
activity  generally  produces  a  reduction  in  W  or  R,  or  both,  and  results  in  a  smaller  risk  contri¬ 
bution  for  factor-X. 

For  example,  user  interface  technology  is  very  important  to  AFTOMS.  Pre-POC,  its  risk  con¬ 
tribution  was  perceived  to  be  very  high  because  of  the  large  number  of  interfaces  to  be  built 
and  their  importance  to  system  usability  (combining  for  a  high  weighting  W),  and  the  emerg¬ 
ing,  still  problematic  state  of  technologies  (X-Windows,  graphic  user  interface  development 
tool  kits,  etc.)  for  developing  distributed,  hardware-independent  interfaces  (producing  a  high 
R  value).  The  POC  activity  reduced  this  risk  contribution  significantly  by  lowering  W  (since  it 
demonstrated  that  any  AFTOMS  user  interface  could  be  developed  as  a  minor  variation  on  a 
few  basic  types),  and  by  lowering  R  (since  working  with  the  technology  products  disclosed 
problem  areas  and  showed  that  they  could  be  resolved  satisfactorily).  Thus,  aside  from  the 
issue  of  distributed  performance,  the  post-POC  risk  contribution  of  user  interface  technolo¬ 
gy  is  low  to  moderate  since  the  POC  team  has  confidence  that  any  user  interface  likely  to  be 
specified  for  AFTOMS  can  be  built. 

B6.2.3  Risk  Estimating 

The  following  quantitative  estimates  of  weighting  (W)  and  risk  (R)  were  developed  for  the 
baseline  pre-POC  case. 

Based  on  applying  extensive  experience  (gained  in  developing  military  systems)  to  high-level 
requirements  information  specific  to  AFTOMS  (gained  doing  pre-POC  and  POC  work),  the 
pre-POC  weightings  (W)  of  30, 25, 20,  and  25,  respectively,  were  assigned  to  the  four  first-le¬ 
vel  risks;  they  are  shown  in  FIGURE  B6-1  next  to  each  risk.  The.>e  initial  four  weightings  add 
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up  to  100,  the  total  buildability  risk.  Continuing  in  this  fashion  downward  through  FIGURE 
B6-1,  while  comparing  various  risks  to  each  other  and  consolidated  weightings  to  their  con¬ 
stituents.  all  the  W-values  were  estimated,  adjusted,  and  used  in  this  analysis.  These  baseline 
W-estimates  are  also  listed  in  the  first  numerical  column  of  TABLE  B6-1. 

The  R-value  for  each  risk  factor  was  judged  as  High  (H),  Medium  (M),  or  Low  (L),  where 
high  represents  a  50%  greater  risk  than  medium  and  low  is  50%  less  risky  than  medium.  For  a 
system  in  which  performance  is  paramount  in  importance  (e.g.,  Apollo  or  Star  Wars)  the 
spread  between  high,  medium,  and  low  would  be  set  much  greater,  but  for  AFTOMS  the  nar¬ 
rower  spread  is  suitable.  The  resulting  R-estimates  are  listed  in  the  second  numerical  col¬ 
umn  of  TABLE  B6-1. 

Finally,  for  the  baseline  pre-POC  case  the  risk  contribution  (C  =  W  times  R)  for  each 
lowest-level  risk  factor  is  shown  in  numerical  column  3;  for  computability,  it  is  based  on  set¬ 
ting  medium  risk  at  a  level  of  2.  Risk  contributions  for  the  composite  risk  components  are 
obtained  by  adding  up  their  constituent  risk  contributions;  and  the  total  baseline  pre-POC 
buildability'  risk  for  AFTOMS  in  FY91-FY93  under  the  expected  scheduling  conditions  with 
a  good,  quality  RFP  is  estimated  at  2.67,  which  is  one-third  below  a  High  rating. 

The  remaining  columns  of  TABLE  B6-1  show  the  estimated  risk  reduction  results  of  the 
FY89-FY90  POC  work.  Separate  risk  reduction  estimates  were  made  for  the  hands-off, 
hands-on,  and  integrated  total  POC  contributions.  For  each  lower-level  risk  factor,  its  W 
and  R  values  were  judgmentally  re-estimated  in  the  light  of  the  POC  findings,  and  the  com¬ 
puted  risk  contributions  and  consolidations  were  done  as  described  above.  The  results  are 
discussed  below  in  Section  B6.3. 

Although  all  the  weighting  and  risk  estimates  in  this  AFTOMS  Buildability  Model  are  judg¬ 
mental  (and  therefore  difficult  to  substantiate  individually  with  documentation)  they  are  rea¬ 
sonable  as  an  overall  pattern;  and  the  number  of  risk  components  is  large  enough  so  that  the 
total  AFTOMS  Buildability  Risk  is  not  that  sensitive  to  small  differences  in  the  estimated 
values. 
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PARTICULAR  INTEGRATION  APPROACHES  USED 


AFTOMS  buildability  risk  can  be  reduced  by  integrating  POC  findings  into  the  remaining 
phases  of  the  AFTOMS  project:  RFP  development,  proposal  selection  criteria  development, 
architecture  and  design  evaluation,  IV  &  V  oversight  of  development  products,  specific  prob¬ 
lem  and  alternative  solution  evaluation  for  the  SPO,  etc. 

The  TABLE  B6-1  POC  risk  reduction  results  are  summarized  graphically  in  FIGURE  B6-3. 
These  results  are  taken  relative  to  the  baseline  total  AFTOMS  Buildability  Risk  of  High-mi¬ 
nus  (or  2.67)  corresponding  to  a  “Tight"  RFP  (about  350  pages  of  good  quality  technical  re¬ 
quirements)  and  No  POC. 

For  each  POC  activity  scenario  (R:  Report  Only  POC,  D:  Demo  System  Only  POC,  and 
R  +  D:  combined  Report  and  Demo  System  POC),  the  upper  half  of  FIGURE  B6-3  depicts 
the  estimated  minimum  and  maximum  buildability  risk  reductions  for  that  activity  under 
Tight  RFP  conditions.  The  minimum  risk  reduction  estimate  represents  the  case  where  the 
POC  results  are  only  integrated  into  the  RFP  and  proposal  selection  criteria  development 
products  prior  to  contract  award,  and  thereafter  ignored;  whereas,  the  maximum  risk  reduc¬ 
tion  estimate  case  presumes  full  integration  of  POC  findings  into  the  entire  AFTOMS  devel¬ 
opment  and  installation  life  cycle. 

The  bottom  half  of  FIGURE  B6-3  summarizes  the  maximum  risk  reduction  contributions  of 
the  major  risk  components  identified  in  FIGURE  B6-1  for  each  of  the  three  POC  activity 
scenarios. 

B6.3.1  In  Demo  System 

The  Dc  mo  System  Only  scenario  shows  the  contribution  of  this  POC  activity  to  total  build- 
ability  risk  reduction:  the  baseline  2.67  risk  is  redu  >  o  .  '  12  (minimum  reduction)  or  1.17 

(maximum  leduction). 

The  risk  reduction  impact  of  the  Lmo  System  is  greaiv in; 

•  Improving  requirements  quality  (579c)  by  providing  a  functioning  table-top 
model  that  demonstrates  key  requirements  (including  user  interfaces)  and  the 
interactions  between  elements  of  the  AFTOMS  concept; 

•  Reducing  technology  (779c)  and  development  and  support  tool  (839c)  risks  by- 
working  hands-on  with  leading  representative  products  to  build  actual 
AFTOMS  functionality  rather  than  just  doing  generalized  evaluations;  and 

•  Reducing  IV  &  V contractor  (60%)  and  prime  contractor  (60%)  team  risks,  and 
the  response  flexibility  (479c)  risk  by  providing  a  dynamic  functioning  table- 
top  model  of  AFTOMS  that  can  be  kept  current  which  is  a  useful  framework 
for  evaluating  designs,  problems,  and  potential  solutions. 
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B6.3.2  In  Other  Hands-on  Technology  Evaluations 

Many  technology’  products  were  evaluated  individually  before  they  were  either  selected  or 
rejected  for  use  in  the  Demo  System.  Experience  with  the  selected  ones  is  described  in  the 
Supplement  to  this  report  and  is  incorporated  in  Section  B6.3.1;  whereas,  hands-on  experi¬ 
ence  with  the  rejected  ones  is  incorporated  in  Section  B6.3.3.  FY89  rejection  of  technology' 
products  for  use  in  the  Demc  System  should  not  bias  or  preclude  their  reconsideration  for  the 
full-scale  AFTOMS. 

B6.3.3  Other  Assessments  for  FY91-FY93 

The  Report  Only  scenario  shows  the  contribution  of  this  POC  activity  to  total  AFTOMS 
Buildability  Risk  reduction:  the  baseline  2.67  risk  is  reduced  to  2.20  (minimum  reduction)  or 
1.74  (maximum  reduction). 

The  risk  reduction  impact  of  the  AFTOMS  hands-off  analytical  activity,  as  supported  by  rele¬ 
vant  independent  product  evaluations,  is  greatest  in: 

•  Improving  requirements  quality  (37%)  by  thinking  through  the  AFTOMS  con¬ 
cept  and  the  functional  and  technology  requirements  needed  to  realize  it; 

•  Reducing  technology  (62% )  and  development  tool  (50% )  risks  by  investigating 
which  technologies/tools  could  be  used  and  how  they  should  be  used  to  build 
AFTOMS  and  avoid  integration/performance  problems;  and 

•  Reducing  IV  &  V  contractor  (40%)  and  prime  ccntrartor  (40%)  team  risks  by 
providing  a  useful  framework  for  evaluating  designs,  problems,  and  solutions 
during  development. 

Comparing  the  Demo  Only  and  Report  Only  risk  reductions  shows  an  interesting  result:  the 
Demo  Only  risk  reductions  are  greater.  This  is  because  some  Report  Only  thinking  is  still 
required  in  a  Demo  Only  POC  activity’  in  order  to  be  able  to  understand  selected  AFTOMS 
requirements  and  design  a  Demo  System.  Then  the  Demo  Only  adds  to  that  the  risk  reduc¬ 
tion  findings  from  the  hands-on  aspects  of  working  with  technology  products  and  develop¬ 
ment  tools  as  well  as  integrating  requirements  to  obtain  working  AFTOMS  functionality. 
Taken  singly,  the  Demo  Only  is  more  valuable  for  risk  reduction  than  Report  Only,  but  both 
together  are  even  more  valuable  reducing  the  total  risk  to:  1.82  (minimum  reduction)  or  0.97 
(maximum  reduction).  This  risk  reduction  synergy  results  from  the  fact  that  although  there 
is  some  common  ground  covered  by  each  type  of  POC  activity  separately,  there  are  also  many 
issues  that  are  better  explored  using  one  approach  or  the  other.  See  Section  1.2.3  to  under¬ 
stand  the  strengths  and  weaknesses  of  the  hands-on  versus  hands-off  risk  assessment/abate¬ 
ment  approaches. 
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B6.4  RISK  ASSESSMENT 


The  system  buildability  risks  for  FY91-FY93  and  beyond  are: 

•  Organizational  Issues  Risk:  This  incorrectly  or  inappropriately  maps 
AFTOMS  functionality  and  responsibility  to  existing  or  new  organizational 
elements  which  can  affect  the  acceptance  and  implementation  success  of 
AFTOMS; 

•  Misuse  or  Non-use  of  POC  Results  Risk:  This  fails  to  take  full  advantage  of 
the  FY89-FY90  POC  work  (as  described  in  Sections  2,  3,  and  4)  in  order  to 
maximize  the  potential  for  total  buildability  risk  reduction  (e.g.,  limiting  POC 
use  to  pre-award  activities  and  SPO  products  would  only  reduce  the  total  risk 
from  High-minus  to  Medium-minus  rather  than  all  the  way  down  to  Low,  as  is 
possible);  and 

•  “Loose”  RFP  Risk:  This  awards  the  contract  on  the  basis  of  a  brief  (about 
50-page)  technical  specification  that  does  not  discriminate  well  between  pro¬ 
posed  solutions  and  relies  on  the  contractor  to  develop  the  full  set  of  detailed 
specifications  required  to  build,  test,  and  validate  AFTOMS.  Because  of  the 
tight  project  scheduling  constraint,  this  would  present  developers  with  a  mov¬ 
ing  requirements  target,  increase  parallelism  of  activities  to  keep  to  schedules, 
add  to  integration  risks,  continually  pose  configuration  control  problems,  in¬ 
crease  the  number  of  problems  to  solve,  and  probably  result  in  a  lower-quality 
system  that  will  require  Engineering  Change  Proposals  (ECPs)  to  make  accept¬ 
able.  Using  the  buildability  model  to  quantify  this,  a  “loose”  RFP  would  result 
in  a  final  total  AFTOMS  Buildability  Risk  of  Medium,  even  if  full  advantage  is 
taken  of  the  POC  findings,  rather  than  the  Low  risk  that’s  possible  with  a  Tight 
RFP;  otherwise,  the  risk  would  remain  High  if  POC  is  only  used  for  pre-award 
activities. 

B6.5  RISK  ABATEMENT 

The  system  buildability  risks  can  be  abated  as  follows: 

•  Organizational  Issues  Risk:  This  risk  was  beyond  the  scope  of  the  FY89 
-FrY90  POC  study,  but  the  risk  should  be  assessed  by  the  AFTOMS  SPO  since 
it  can  impact  RFP  requirements,  training  requirements,  and  the  strategy  for 
installing  AFTOMS. 

•  Misuse  or  Non-use  of  POC  Results  Risk:  Reduce  this  risk  by  fully  integrating 
the  FY89-FY90  POC  work  into  both  pre-and  post  contract  award  activities  to 
maximize  the  potential  for  total  AFTOMS  Buildability  Risk  reduction. 
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•  "Loose”  RFP  Risk:  Reduces  this  risk  by  using  the  POC  findings  to  focus  re¬ 
sources  in  the  time  available  on  particularly  problematic  or  risky  specification 
areas,  thereby  selectively  tightening  up  the  RFP  in  those  areas  offering  the  larg¬ 
est  risk  reduction  payoff.  Also,  a  more  intensive  FY90  and  post-award  Demo 
System  enhancement  activity  could  increase  the  downstream  POC  payoff  (e.g., 
Type  C  functionality  could  first  be  evaluated  and  integrated  into  the  Demo  Sys¬ 
tem  to  determine  the  best  approach  for  its  integration  into  the  full-scale 
AFTOMS);  similarly,  other  important  issues  could  be  investigated  in  parallel 
with  the  main  AFTOMS  activity  without  risking  its  progress. 
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SECTION  B7: 

Reliance  on  Confonnance  to  Standards 


B7.1 


SCOPE  AND  RELEVANCE 


Since  certain  standards  are  mandated  by  the  U.S.  Government  there  is  no  question  that  AF- 
TOMS  will  have  to  conform  to  standards.  Conformance  to  mandated  standards  must  be  total 
and  direct  (explicit)  while  conformance  to  other  optional  standards  may  be  none,  partial  or 
total,  and  direct  or  indirect  (implicit).  Indirect  conformance  occurs  when  an  integrated  com¬ 
mercial  technology'  product  itself  conforms  to  certain  standards. 

Applicable  standards  include  data  interchange  standards  as  well  as  de  facto  and  de  jure  com¬ 
puter  industry  standards.  Each  standard  has  its  particular  unique  mix  of  advantages  and  dis¬ 
advantages  (relative  to  the  needs  of  AFTOMS)  which  can  impact  AFTOMS  development, 
performance,  operational  usefulness,  and  life-cycle  costs.  These  costs  arise  from  post-IOC 
maintenance,  enhancement,  modification,  and  upgrading  efforts.  Most  standards  are  them¬ 
selves  constantly  evolving  to  keep  up  with  changes  in  technology’,  market  factors,  and  the 
needs  of  users  of  standards.  Integrating  several  commercial  technology  products,  each  sup¬ 
porting  or  non-supporting  particular  standards  partially  or  completely,  can  prove  trouble¬ 
some  because  of  the  potential  conflicts  and  resulting  incompatibilities. 

Therefore,  risks  exist  for  AFTOMS  in  relying  on  conformance  to  standards  both  individually 
and  as  an  integrated  group;  and  such  risks  cannot  be  totally  avoided.  The  objective  of  this 
section  is  to  explore  the  nature  of  these  risks  and  propose  key  elements  of  a  strategy  for  abat¬ 
ing  them. 

B7.2  STATE  OF  INTEGRATION  FEASIBILITY 

The  state  of  integration  feasibility  is  assessed  by  first  reviewing  general  considerations  about 
standards,  then  defining  a  framework  for  viewing  the  integration  of  standards,  and  finally  eva¬ 
luating  the  problems  and  feasibility  of  integrating  standards  to  facilitate  building,  using, 
maintaining  and  modifying  AFTOMS. 

B7.2.1  General  Considerations 

Standards,  used  properly,  offer  several  significant  advantages  in  developing  large-scale  soft¬ 
ware  systems;  these  are: 

•  Ability  to  replace  numerous  detailed  variants  with  a  single  standard  option  (or 
smaller  number  of  options)  that  are  easier  to  build  and  maintain,  thereby  re¬ 
ducing  the  quantity  of  customized  integration  required; 

•  Opportunity  to  buy  and  integrate  Commercial  Off-The-Shelf  (COTS),  stan¬ 
dardized,  sophisticated  functionality  rather  than  have  to  build  it  customized, 
thereby  saving  development  time  and  cost,  and  leveraging  available  expertise; 

•  Benefit  from  the  higher  reliability  inherent  in  standardized  functionality  as  it 
has  undergone  heavier  testing  and  usage  in  more  varied  circumstances,  thereby 
assuring  higher  quality”,  and 


•  Benefit  from  the  controlled  flexibility  afforded  by  standards  to  upgrade  stan¬ 
dardized  functionality,  add  new  functionality,  port  to  other  hardware  plat¬ 
forms,  and  support  new-  integration  objectives,  whether  in  functionality  or  stan¬ 
dards. 

Standards  also  have  several  potential  disadvantages;  these  are: 

•  Tendency  to  freeze  the  state  of  the  technology  used  below  the  constantly 
emerging  state  of  the  art,  thereby  sacrificing  potential  performance  or  func¬ 
tionality  gains; 

•  Necessity  to  accept  excess  functionality’  needed  to  fully  support  a  standard  that 
is  irrelevant  to  the  task  at  hand,  thereby  adding  to  software  overhead; 

•  Compromise  to  use  a  standard  w’hich  does  not  do  the  required  job  because  the 
standard  itself  is  either  incomple  te,  too  restrictive,  or  a  partial  mismatch,  there¬ 
by  requiring  additional  customized  support; 

•  Gross  instability  or  obsolescence  if  the  standard  is  not  part  of  a  predictably 
evolving  technology,  or  is  outgrown  by  hardware  advances,  or  lacks  the  stability 
of  substantial  de  facto  usage,  or  is  not  widely  supported  by  vendors  or  the  gov¬ 
ernment;  and 

•  Unpredictable  or  negative  interaction  effects  of  combining  and  integrating 
multiple  standards,  some  of  which  may  be  conflicting. 

Essentially,  the  open  system  architecture  viewpoint  argues  that  reliance  on  conformance  to 
standards  is  a  sensible  system  development  strategy.  It  acknowledges  that  the  traditional 
goals  of  using  the  latest  technology,  maximizing  performance,  minimizing  resource  utiliza¬ 
tion,  and  customizing  functionality  to  support  cosmetic  variants  -while  still  important  to  some 
degree-  are  now  outweighed  by  the  long-term  goals  of  usage  and  maintenance  productivities. 
Therefore,  the  best  system  development  strategy  for  a  large-scale,  long-lived,  heteroge¬ 
neous,  operational  system  like  AFTOMS  is  to  take  advantage  of  the  benefits  of  particular 
standards  while  neutralizing  or  managing  their  problems;  and  if  that  is  not  possible,  then  bal¬ 
ancing  their  benefits  and  their  associated  problems.  This  requires  the  successful  integration 
of  many  standards.  The  following  presents  a  framework  for  defining  and  evaluating  such  an 
integration. 

B7.2.2  Framework  for  Standards  Integration 

Individual  applicable  standards  are  categorized,  listed,  and  characterized  in  TABLE  B7-1  by 
compliance  status,  benefits,  and  comment  (if  applicable). 

Compliance  status  is  either.  Gov’t  Req'd,  which  marks  those  standards  that  are  mandated  by 
the  government  and  apply  to  AFTOMS;  AFTOMS  Req’d,  which  identifies  those  standards 
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that  are  essential  to  the  success  of  AFTOMS;  or  AFTOMS  Opt’l,  which  identifies  those  op¬ 
tional  standards  that  may  be  useful  to  AFTOMS  given  a  particular  design  approach. 

Benefits  are  split  into  two  major  categories,  each  with  two  subcategories,  as  follows: 

•  The  first  major  category  identifies  those  standards  that  simplify  either  using  the 
system  (Use)  or  building  it  (Build),  thereby  reflecting  near-term  benefits;  and 

•  The  second  major  category  identifies  those  standards  that  provide  long-payoff 
benefits  by  facilitating  either  maintainability’  (Maint.)  or  future  integration  (In- 
teg.)  with  other  technical  order  and  CALS  systems. 

An  asterisk  preceding  the  standard's  name  indicates  hands-on  use  of  that  standard  in  the 
AFTOMS  Demo  System.  Superceding  or  related  standards  or  other  plans  are  noted  in  the 
comment  column  of  the  table. 

It  is  assumed  that  AFTOMS  is  not  subject  to  any  overriding  standards  (such  as  safety  for  a 
nuclear  facility  or  survivability  for  a  critical  weapon  system)  which  would  take  precedence 
over  the  standards  listed  in  TABLE  B7-1.  Therefore,  only  integration  of  the  listed  standards 
need  be  considered  for  risks. 

Using  this  framework,  the  integration  risk  assessment  proceeds  in  decreasing  priority  order: 
from  left-to-right  by  column  (first  the  Gov’t  Req’d  group,  then  the  AFTOMS  Req’d  group, 
and  finally,  the  AFTOMS  Opt’l  group),  and  top-to-bottom  by  each  standard  within  that  col¬ 
umn.  For  each  standard  within  a  column,  its  integration  risk  is  assessed  against  all  the  stan¬ 
dards  already  integrated  in  the  preceding,  higher-priority’  columns  and  against  the  higher- 
listed  standards  in  its  own  column.  Using  the  data  gathered  in  the  POC  activity,  this  risk  asses¬ 
sment  identifies  the: 

•  Standards  gaps; 

•  Conflicting  incompatibilities; 

•  Unusual  current  or  future  instabilities; 

•  Constraining  inflexibilities; 

•  Performance  degradation;  and  the 

•  Status  of  the  standard  (de  facto  or  de  jure,  substantially  defined  or  not,  ac¬ 
cepted  or  controversial,  and  is  it  in  competition  with  another  standard). 
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TABLE  B7-1.  AFTOMS  STANDARDS  FRAMEWORK 
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•Indicates  Hands-on  POC  Usage 
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FIGURE  B7-1.  AFTOMS  STANDARDS  FRAMEWORK  (CONT’D) 
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B7.2.3  Integration  Feasibility  and  Problems 
B7.2.3.1  Government  Required  Standards 
Data  Encoding  and  Interchange  Standards 

The  Data  Encoding  and  Interchange  standards  are  fairly  well  integrated  except  for  some 
overlap  between  Initial  Graphics  Exchange  Standard  (IGES)  and  Computer  Graphics  Meta¬ 
file  (CGM).  Since  IGES  currently  has  operational  problems,  it  will  be  supplanted  in  the  mid- 
to-late  1990's  for  sophisticated  technical  applications  by  an  approved  Product  Data  Ex¬ 
change  Standard  (PDES).  IGES  is  inferior  to  CGM  for  simple,  AFTOMS-style  2-D  techni¬ 
cal  illustrations.  CGM  or  raster  Consultative  Committee  for  International  Telephone  and 
Telegraph  (CCl  11  )/Group  4  should  take  precedence  in  AFTOMS.  However,  if  the  develop¬ 
ment  and  operational  usefulness  of  CGM  is  delayed  beyond  FY91,  then  IGES  support  may 
have  to  be  provided  in  AFTOMS  to  accept  vectorized  TOs  from  contractors.  The  other  stan- 
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dards  in  this  group  are  complementary.  The  biggest  risks  in  this  group  arise  from  the  slow 
development  of  validated  DTD  and  OSs  to  support  MIL-STD  1840. 

Digital  Communications  Standards 

The  Digital  Communication  standards  are  also  fairly  well  integrated  since  they  support  vari¬ 
ous  elements  of  the  master  OSI  architecture  for  interconnection.  Only  the  Ethernet  and  To¬ 
ken  Ring  standards  overlap  because  they  provide  competing,  alternative  architectures  for 
LANs.  Either  one  can  be  used  in  AFTOMS.  But  given  that  DoD's  Unified  Local  Area  Net¬ 
work  Architecture  (ULANA)  program  is  installing  Ethernet  earlier  than  Token  Ring  LANs, 
and  that  most  of  AFTOMS-relevant  technology  products  provide  extensive  support  for  the 
Ethernet  protocol,  AFTOMS  should  favor  Ethernet  except  where  a  particular  technology 
product  requires  the  Token  Ring  protocol  or  where  the  deterministically  predictable  per¬ 
formance  of  token  passing  is  required. 

Software  Development  Standards 

The  Software  Development  standards  are  currently  partially  integrated,  but  should  be  further 
integrated  by  FY91.  There  are  several  different  versions  of  UNIX  (AT&T  V3,  Berkeley  4.3 
Berkeley  Systems  Development  (BSD),  Open  Software  Foundation  (OSF)  1 .0,  etc.),  which  do 
not  yet  support  the  Portable  Operating  System  Interface  (POSIX)  standard.  AT&T's  V.5  ver¬ 
sion  reportedly  will  be  POSIX-compliant.  POSIX  itself  is  evolving  and  being  completed.  For 
example.  POSLX  now  only  defines  an  interface  between  programs  written  in  the  C  language 
and  the  UNIX  operating  system;  work  is  currently  underway  to  define  an  Ada  language  adap¬ 
tation  for  POSIX  and  a  language-independent  version  of  POSIX.  POSIX  work  is  also  being 
performed  in  networking  and  security  issues. 

There  are  no  significant  integration  problems  between  standards  listed  in  the  different  groups 
within  the  Gov't  Req'd  column. 

B7.2.3.2  AFTOMS  Required  Standards 

The  Data  Encoding  and  Interchange  standards  and  the  Digital  Communication  standards  in 
this  column  are  completely  consistent  with  the  same  standards  in  the  preceding  column,  in¬ 
cluding  the  critical  need  for  validated  DTD  and  OS  specifications  to  support  MIL-STD  1840. 

The  standards  listed  in  the  Data  Storage  &  Access  group,  Digital  User  Interfacing  group. 
Platforms  &  Hardware  group,  Document  Structure,  etc.,  group,  and  the  Training  group  focus 
on  additional  functionalities  which  do  not  conflict  with  any  of  the  preceding  standards  dis¬ 
cussed  and,  therefore,  should  pose  no  significant  integration  risks.  Over  the  next  few  years, 
official  support  for  some  of  these  standards  will  develop  and  become  incorporated  into  the 
Gov’t  Req’d  column. 

In  the  Software  Development  group,  American  National  Standard  Institute  (ANSI)  C  and 
Computer-Aided  Support  Environment  (CASE)  are  additions  to  the  preceding  discussion. 


B7-6 


Both  are  complementary.  POSIX,  which  supports  C,  will  also  support  ANSI  C;  and  POSDC 
will  support  portions  of  a  UNIX-based  CASE  environment  for  development  and  mainte¬ 
nance.  Ada  (a  programming  language  per  MIL-STD  1815),  which  could  be  used  on  AF- 
TOMS  to  develop  the  design,  is  supported  by  a  standard  CASE  environment  called  the  Ada 
Programming  Support  Environment  (APSE).  Non- Ada  CASE  environments  are  not  likely  to 
become  standardized  soon. 

There  are  no  significant  integration  problems  between  standards  listed  in  the  different  groups 
within  the  AFTOMS  Req’d  column. 

B7. 2.3.3  AFTOMS  Optional  Standards 

The  1GES.  PDES,  and  Token  Ring  standards  appearing  in  this  AFTOMS  Opt’l  column  have 
already  been  discussed;  they  are  not  central  to  the  success  of  the  AFTOMS  concept,  but  may 
have  to  be  supported  because  of  specific  considerations  for  MIL-STD  1840  contractor  com¬ 
pliance,  future  integration  with  the  Product  Definition  Data  (PDD)  system  concept,  and  com¬ 
mercial  application  constraints. 

The  Data  Storage  &  Access  group  lists  optical  disk  for  archiving  as  optional  because  stan¬ 
dards  are  essentially  non  existent  and  the  government  does  not  yet  recognize  optical  media  as 
officially  trustworthy  media  for  permanent  storage. 

The  WYSIWYG  standard  in  the  Digital  User  Interfacing  group  is  a  useful  optional  standard 
for  Tier  2  processing.  It  is  being  integrated  with  the  PDL  standard,  and  poses  no  significant 
integration  problems  with  other  standards  listed. 

In  the  Digital  Communication  group,  Transmission  Control  Protocol/Lntemet  Protocol 
(TCP/IP)  and  Network  File  System  (NFS)  are  existing  standards  that  will  be  superceded  by 
Government  Open  System  Interconnect  Protocols  (GOSIP)  requirements  to  go  to  TP4/IP, 
but  will  still  be  supported  in  practice  as  a  subset  or  variant.  Since  GOSIP  does  not  cover  work¬ 
station-based  environments,  AFTOMS  may  have  some  flexibility  in  choosing  which  stan¬ 
dards  to  support  if  such  a  choice  provides  significant  advantages. 

In  the  Software  Development  group,  C++  and  Ada  are  listed  as  AFTOMS  Opt’l.  C  +  +  is 
listed  because  it  is  object-oriented,  preferable  to  C  for  developing  certain  types  of  software, 
compatible  with  C  and  the  preceding  standards,  as  well  as  the  base  language  for  UNIX  V.5 
and  a  growing  list  of  sophisticated  UNIX-based  application  technologies.  Whereas,  Ada  is 
listed  because  it  may  only  be  suitable  for  the  design,  but  not  the  implementation  of  AFTOMS; 
the  reason  being  that  X-Windows,  which  is  critical  to  AFTOMS,  is  not  yet  supported  in  an 
Ada  environment. 

Finally,  the  Office  Document  Architecture/Office  Document  Interchange  Format  (ODA' 
ODIF)  standard  is  listed  as  a  future  AFTOMS  possibility  for  supplementing  SGML  to  control 
and  interchange  formatted  documents  like  office  memos.  At  best,  it  is  an  incomplete  stan- 
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dard  which  is  not  yet  required  for  CALS,  but  may  become  incorporated  into  a  future  version 
of  GOSIP.  Future  integration  with  PDD  may  require  support  for  the  Electronic  Data  Inter¬ 
change  (EDI)  standard  within  AFTOMS  which  will  be  a  part  of  MIL^-STD  1840.  There  are  no 
significant  integration  problems  between  standards  listed  in  the  different  groups  within  the 
AFTOMS  Opt’I  column. 

B7.2.3.4  Implicit  Standards 

Implicit  standards  are  important  because  AFTOMS-integrated  application  technolog}’ prod¬ 
ucts  could  embody  some  standards  which  may  pose  integration  risks  with  any  of  the  foregoing 
standards.  This  is  less-troublesome  for  UNIX-based  products  which  are  less  proprietary- 
oriented  in  general,  and  therefore,  are  more  likely  to  provide  incomplete  support  of  stan¬ 
dards  rather  than  present  incompatibilities.  Most  likely,  AFTOMS,  will  integrate  the  follow¬ 
ing  four  critical  application  technologies:  DMS,  RDBMS,  UIMS,  and  ODS. 

DMS  products  are  not  now  standardized;  they  use  proprietary  file  structures  which  make  the 
AFTOMS  TO  databases  less  portable  and  offer  significantly  different  functional  capabilities. 
Therefore,  they  are  less  compatible.  Newer  DMS  products  are  showing  a  trend  toward  using 
a  RDBMS  or  an  object-oriented  database  technolog}'  for  document  storage  and  manage¬ 
ment.  However,  the  lack  of  DMS  standards  is  likely  to  continue  for  several  years  and  adds 
risk  to  future  life-cycle  maintainability. 

RDBMS  products  all  support  ANSI  SQL  which  provides  a  standard  for  guaranteeing  schema 
and  data  portability  across  products  so  they  add  minimal  risk  to  standards  integrations. 

UIMS  products  are  relatively  new  and  most  are  based  on  the  X- Windows  standard  to  obtain 
network  capabilities  and  device  independence.  However,  they  do  use  competing  incompat¬ 
ible  toolkits  to  construct  the  aesthetic  user  interface  environment.  In  a  few  years,  these  tool¬ 
kits  will  mature  and  evolve  into  one  or  two  de  facto  standards  (i.e,  Open  Look  from  UNIX 
Int.,  Motif  from  OSF,  etc.). 

ODS  products  are  just  emerging;  in  general,  they  support  a  Program  Design  Language  (PDL) 
version  for  screen  output,  usually  display  PostScript.  In  the  future,  they  will  likely  support 
Standard  PDL  (SPDL),  a  standard  PDL  being  defined  by  International  Standards/Services 
Organization  (ISO).  ODS  products  have  to  link  into  a  DMS  product  to  obtain  the  displayable 
content  which  can  pose  an  integration  problem  with  some  DMS  systems. 

B7.3  PARTICULAR  INTEGRATION  APPROACHES 

One  of  the  most  important  goals  of  the  Demo  System  effort  was  to  employ  as  many  com¬ 
puter-based  standards  as  possible.  The  POC  activity  has  identified  standards  as  one  of  the 
critical  success  factors  for  AFTOMS.  In  selecting  the  component  modules,  the  Demo  System 
team  had  two  main  criteria: 

•  Demonstrate  the  major  functional  activities  identified  in  the  AFTOMS  system 
concept:  and 


•  Develop  a  heterogeneous  system  by  adhering  to  as  many  government  and  in¬ 
dustry  standards  as  possible. 

The  computer  industry  has  had  a  major  change  in  its  app-oach  to  building  systems  over  the 
past  few  years.  The  Seybold  Report  on  Publishing  Systems  refers  to  the  modem  systems  as 
Fourth  Generation  Systems.  The  fundamental  concept  is  that  systems  are  built  and  integrated 
from  hardware  and  software  components  readily  available  in  the  marketplace  from  many  di¬ 
verse  suppliers.  Integration  is  the  main  task  and  adherence  to  standards  make  this  approach 
viable.  Most  major  suppliers  in  the  computer  industry  adhere  to  this  concept  and  are  building 
components  and  system  products  in  this  manner. 

The  AFTOMS  Demo  System  team  v.anted  to  employ  the  same  strategy.  However,  this  revo¬ 
lution  in  the  computer  industry  began  only  recently  and  most  of  these  type  of  products  are 
recent  offerings  or  pre-release  (Beta)  versions.  The  Demo  System  activity  was  scheduled  for 
development  in  FY89  and  completion  in  early  FY90.  The  above-stated  conditions  forced 
another  set  of  decision  filters  in  regard  to  the  selection  of  components  adhering  to  standards: 

•  Decisions  had  to  be  based  on  adhering  to  the  schedule; 

•  Froducts  selected  (even,  if  pre-releases)  needed  to  have  some  level  of  support 
from  the  vendor;  and 

•  Products  selected  needed  to  be  integratable  with  the  other  selected  compo¬ 
nents. 

Despite  all  those  factors  in  the  dec;sion  process,  a  significant  number  of  products  supporting 
industry  standards  were  employed.  They  include: 

•  UNIX: 

•  Ethernet; 

•  Token  Ring; 

•  TCP/IP; 

•  NFS; 

•  X-Windows; 

•  SQL; 

•  C; 

•  Pos'Script;  and 

•  eOML 
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The  use  of  X-Windows  proved  to  be  a  big  success  story.  A  major  concern  of  Air  Force  man¬ 
agement  was  the  protection,  portability,  and  coexistence  of  the  software  with  other  CALS 
software.  X-Windows  has  been  created  and  advertised  as  the  solution  to  these  key  issues. 
The  experience  in  the  Demo  System  activity  bears  this  promise  out.  The  user  interface  soft¬ 
ware  for  AFTOMS  was  developed  on  one  manufacturer's  workstation  with  their  X  product 
(window  system  and  toolkit)  and  subsequently  ported  and  executed  on  two  different  worksta¬ 
tions  in  their  X- Window  environments.  The  user  interface  looks  the  same  to  the  users  (except 
for  minor  details).  This  software  could  coexist  with  other  CALS  applications  in  any  X-Win- 
dow  environment  which  addresses  the  problem  of  proliferation  of  workstations  and  terminals 
for  multi-applications  users  in  the  CALS  world.  Also,  this  solution  allows  the  application  to 
be  totally  independent  of  the  hardware  and  operating  system. 

Another  standard  that  was  employed  with  a  successful  outcome  was  NFS.  CALS,  and  certain¬ 
ly  .AFTOMS.  will  consist  of  many  computer  systems  with  their  proprietary  underlying  file  sys¬ 
tems.  These  systems  need  to  interact  with  each  other  to  access  and  transfer  information 
stored  in  these  file  systems.  NTS  is  designed  to  solve  this  problem.  The  Demo  System  suc¬ 
cessfully  used  NFS  to  allow  the  proprietary  file  systems  to  interact  because  they  all  support  the 
NTS  standard. 

Within  AFTOMS.  the  data  management  activity  will  make  heavy  use  of  an  RDBMS.  The 
basic  components  of  AFTOMS  are  the  user  interface  and  the  database.  The  user  interface 
repeatedly  and  consistently  field;-  user  requests  requiring  an  access  (ie.  query  or  update)  to  the 
database.  In  the  relational  database  model,  SQL  functionality  provides  this  access  capability. 
many  vendors  support  this  SQL  interface.  The  Demo  System  user  irrerface  software  uses 
embedded  SOL  calls  mixed  with  C  language  code  to  interface  to  its  database.  This  SQL  inter¬ 
face  will  allow  a  change  to  a  diffc.ent  RDBMS  product  without  having  to  mod:r  ■  the  Demo 
System  user  interface  software. 

B7.4  RISK  ASSESSMENT 

The  following  risks,  which  complicate  AFTOMS  integration,  were  identified: 

•  Standards  Gap  Risk:  DMS  technology  products  lack  standards  which  could 
increase  AFTOMS  life— cycle  costs;  and  optical  media  are  not  acceptable  as  a 
standard  yet  for  archiving  permanent  data  within  a  government  environment, 
which  could  force  interim  use  of  paper  or  microfilm  for  archival  storage.  De¬ 
velopment  of  validated  DTDs  and  OSs  is  a  slow  process:  these  suppon  MIL- 
STD  1840. 

•  Standards  Interaction  Risk  As  an  implementation  language,  Ada  does  notyet 
support  POSIX  or  X-Windows  and  w.-'uld  complicate  AFTOMS  development 
and  integration. 

•  Standards  Instability  Risk:  Affecting  the  evolving  POSIX-standardized  fla¬ 
vor  of  UNIX  to  a  small  degree;  and  the  maturing,  settling  down  of  emerging 
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technologies:  Optical  media 'and  devices,  CASE  environments,  UEMS,  and 
CDS. 

•  Standards  Obsolescence  Risk:  This  is  a  minor  risk  as  the  1GES,  TCP/IP,  and 
NFS  standards  are  being  superceded  by  other  standards;  these  sets  of  standards 
may  need  to  be  supported  based  on  the  details  of  the  AFTOMS  design. 

B7.5  RISK  ABATEMENT 

Risk  abatement  strategies  for  the  four  classes  of  identified  risk  follow". 

•  Standards  Gap  Risk:  If  a  DMS  functionality-versus-standards  tradeoff  must 
still  be  made  in  FY91,  then  select  that  DMS  technology  product  which  supports 
the  complex  technical  publishing  and  document  configuration  control  require¬ 
ments,  yet  is  on  a  development  path  that  will  make  the  DMS  product  less  pro¬ 
prietary  over  time.  To  handle  the  arcniving  problem,  perhaps  optical  media 
could  be  used  for  semi-permanent  archiving  (e.g.  10-15  years)  until  the  media 
standards  become  solidified  and  optical  media  become  accepted  by  govern¬ 
ment  as  trustworthy  for  permanent  storage.  In  the  meantime,  archival  integrity' 
could  be  sampled  periodically,  and  technical  order  data  rewritten  automatical¬ 
ly  to  resolve  any  quality  deterioration.  Development  and  validation  of  stan¬ 
dardized  DTDs  and  OSs  should  remain  a  high  priority  program  issue. 

•  Standards  Interaction  Risk:  Ada  should  not  be  used  at  all  or  used  only  as  a 
design  language  to  gain  design  portability",  then  use  C  or  C+  +  to  implement 
the  portable  design  description. 

•  Standards  Instability  Risk:  Minimize  dependence  on  unstable  or  unpredict¬ 
able  standards  (which  is  not  easily  possible  in  AFTOMS),  and  design  in  flexibil¬ 
ity  using  interfaces,  logical  objects,  or  software  layering  to  absorb  changes  in 
these  standards;  avoid  tight  integration. 

•  Standards  Obsolescence  Risk:  Localized  effects  of  conflicts  or  overlaps  be¬ 
tween  standards  can  be  minimized  through  design  by  constraining  standards  to 
independent  functional  areas,  separating  standards  by  system  element  loca¬ 
tion,  layering  standards,  and  by  controlling  standards  through  networked  sys¬ 
tem  administration. 
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BS.l  SCOPE  AND  RELEVANCE 

In  general,  each  dimension  of  integration  in  this  report  focuses  on  a  particular  view  into  AF- 
TOMS  which  evaluates  aspects  of  many  functionalities,  technologies,  and  related  issues  to 
explore  the  risks  and  implications  associated  with  that  viewpoint.  In  fact,  the  same  area  of 
functionality,  technology,  or  issue  may  be  represented  in  more  than  one  dimension  of  integra¬ 
tion,  which  cannot  be  avoided  in  a  complex  interactive  system  such  as  AFTOMS;  but  the  re¬ 
sulting  exploration  is  not  the  same  since  the  integrating  focus  of  each  dimension  is  different. 
The  resulting  exploration  of  any  complex  topic  from  multifocused  viewpoints  provides  a  more 
thorough,  understanding  of  that  topic.  Therefore,  several  topics  already  partially  covered  in 
other  sections  are  revisited  in  this  section  from  the  viewpoint  of  operational  utility. 

The  focus  of  operational  utility  is  actual  use  of  AFTOMS  after  it  is  built;  that  is,  what  are  the 
important  considerations  and  risks  in  making  AFTOMS: 

•  Realize  its  projected  benefits  as  quickly  as  possible  after  Initial  Operational 
Capability  (IOC); 

•  More  productive  in  day-to-day  use;  and 

•  Support  future  enhancements  and  integration  with  other  technical  order  or 
technical  data  systems  which  emerge  from  the  CALS  initiative. 

The  \iewpoint  and  scope  of  this  section  are  designed  to  identify  the  critical  alternatives  and 
tradeoffs  in  functionality,  technologies,  methods  of  using  the  technologies,  procedures,  etc., 
that  can  be  incorporated  into  the  Full  Scale  Engineering  Development  (FSED)  phase  of  AF¬ 
TOMS  development  which  will  then  leverage  the  operational  utility  of  the  system.  Actions 
taken  after  IOC  will  have  less  leverage,  be  mostly  corrective  in  nature,  and  are  not  considered 
explicitly. 

B8.2  STATE  OF  INTEGRATION  FEASIBILITY 

Discussion  of  relevant,  operational  utility  enhancing  issues  is  facilitated  by  grouping  these 
issues  into  three  categories  to: 

•  Accelerate  startup; 

•  Promote  productive  daily  use  after  installation;  and 

•  Support  long-term  productive  viability. 

B8.2.1  Rapid  Startup 

Although  AFTOMS  is  capable  of  managing  both  a  paper  and  digital  technical  order  environ¬ 
ment,  it  is  primarily  designed  for  (and  operates  most  optimally  in)  a  fully  digital  environment; 
therefore,  any  measures  that  can  accelerate  the  transition  and  progress  toward  a  full-digital 
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environment  will  both  simplify  technical  order  management  and  distribution,  and  increase 
the  benefits  from  AFTOMS.  Such  measures  include: 


•  Intelligent  packaging  and  rapid  installation; 

•  Weapon  System  (WS)  selection  and  digital  technical  order  acquisition  or  scan¬ 
ning  conversion;  and 

•  Adequate  staffing  and  quick  user  training. 

BS. 2.1.1  Intelligent  Packaging  and  Rapid  Installation  of  AFTOMS 

Intelligent  packaging  includes  a  weapon  system  configuration  tool,  good  quality  system  and 
operational  documentation,  together  with  automated,  and  mostly,  standardized  installation 
procedures. 

The  WS  configuration  tool  would  define  an  AFTOMS  configuration  and  time-based  data¬ 
base  loading  plan  appropriate  to  the  particular  characteristics  of  a  TOMA's  weapon  system. 
The  configuration  tool  would  specify  required  resources  (i.e.,  workstation  platforms,  printers, 
database  sizing,  archival  sizing,  optical  disk  devices,  LAN  &  WAN  communications,  software 
functionality  distribution,  interfaces  to  ATOS  I  and  G022,  handling  contingencies  and  surviv¬ 
ability  problems,  etc.)  to  handle  the  weapon  system;  and  adapt  the  configuration  to  account 
for  ULANA  and  DDN  scheduling.  The  data  loading  plan  would  specify,  the  numbers  of  pa¬ 
per  and  digital  WS  and  commodity  TOs,  the  numbers  of  outstanding  change  requests,  the 
paper-to-digital  conversion  progress,  and  the  numbers  of  Tier  2  operators  needed  for  catalo¬ 
ging 'indexing,  B+  tagging,  change  processing,  etc. 

B8.2.1.2  Digital  Database  Development 

This  measure  addresses  the  size  and  quality  of  the  digital  TO  database  supporting  a  WS 
TOMA  The  size,  as  represented  by  the  percentage  of  the  total  WS  inventory  of  TOs  in  digital 
form,  is  important  to  maximize  the  AFTOMS  benefits  to  the  TOMA  managing  that  WS  suite 
of  TOs.  Therefore,  effective  acquisition  planning 'management  tools  for  timely  acquisition  of 
new  digital  TOs  or  contractor-implemented  changes  to  existing  TOs,  and  an  aggressive  but 
economical  program  of  scanning  conversion  of  paper  TOs  into  digital  form  are  critical  to 
maximizing  the  digital  database  size.  In  fact,  the  scanning  conversion  should  be  performed  in 
anticipation  of  AFTOMS  installation  at  a  WS  TOMA 

Once  a  TO  is  in  digital  form,  its  quality  determines  its  usefulness  for  change  processing  at  Tier 
2  and  on-line  display  at  Tier  4.  Thus,  Type  B-  is  adequate  for  digital  distribution,  but  Type  B 
is  needed  to  facilitate  change  processing,  whereas  Type  B+  provides  superior  information 
tailoring  and  control  to  individual  Tier  4  users.  Depending  on  the  original  Type  A  TO  quality 
and  format  peculiarities,  scanning  conversion  may  only  allow  a  B-  form;  additional  Tier  2 
manual-assisted  work  would  be  required  to  convert  it  to  MIL-STD  184G  compliant  Type  B 
form.  Type  B  +  requires  additional  Tier  2  manual- assisted  work  to  tag  the  TO  contents  for 
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customized  deliver)",  the  degree  of  B4-  tagging  can  be  controlled  incrementally  and  increased 
over  time  (as  experience  is  gained)  to  provide  recurrently  useful  capabilities  to  Tier  4  at  the 
one-time  cost  of  additional  processing  at  Tier  2.  New  digital  TOs  acquired  from  contractors 
should  be  at  least  Type  B  and  perhaps  already  tagged  to  a  specified  level  of  Type  B  + .  Not  all 
the  TOs  in  an  AFTOMS  database  have  to  be  at  the  same  level  of  tagging  quality",  but  if  they 
are  not,  then  some  of  the  above  benefits  are  sacrificed  for  those  at  lower  quality  levels,  and 
certain  automatic  referencing  capabilities  may  only  be  one-sided  (i.e.,  from  B+  to  B  TOs. 
but  not  vice  versa).  However,  for  older  TOs  and  those  that  are  relatively  inactive  in  terms  of 
change  management,  a  lesser  quality  would  be  an  acceptable  economic  tradeoff. 

Type  C  TOs  will  be  stored  separately  from  the  Type  B  class  database  since  Type  C  TOs  utilize 
an  incompatible  data  model  and  will  be  delivered  separated  to  Tier  3.  Contractors  will  pres¬ 
umably  deliver  them  in  a  Type  C  compliant  format  which  is  yet  to  be  defined. 

B8. 2.1.3  Staffing  and  User  Training 

Adequate  staffing  is  needed  initially,  particularly  at  Tier  2.  to  perform  the  cataloging,  index¬ 
ing.  and  tagging  of  a  new  digital  database  to  prepare  it  for  distribution  by  AFTOMS;  then,  for 
working  and  reducing  the  backlog  of  outstanding  change  requests  to  improve  the  accuracy  of 
the  digital  database. 

Good  user  training  is  needed  to  make  effective  use  of 'he  AFTOMS  capabilities.  AFTOMS 
design  itself,  in  terms  of  simplified  consistent  interfaces  and  interactive  help  and  training  faci¬ 
lities,  should  reduce  the  training  burden  overall.  But  the  residual  burden  requires  training 
support  which  will  vary  by  function:  Tier  4  needs  will  be  minimal,  whereas  Tier  2  publishing 
technicians  will  need  the  most  training  support.  Type  C  capabilities  wil’  require  additional 
training  complexity  and  time  at  Tiers  2  and  3.  However,  in  no  case  should  it  require  more  »han 
a  few  days  of  training  at  the  outset  to  begin  performing  productive  work. 

B8.2.2  Productive  Daily  Use 

Once  AFTOMS  is  past  its  transient  startup  phase  at  a  TOMA  it  will  be  ready  for  productive 
daily  operational  use.  AFTOMS  productivity  can  be  measured  at  the  TOM  A  and  AFTOM  A 
levels  by  how  well  the  system: 

•  Distributes  TOs; 

•  Reduces  the  change  request  backlog  and  correction  turnaround  time; 

•  Increases  the  accuracy  level  of  distributed  TOs; 

•  Improves  verification  accuracy  and  timeliness; 

•  Improves  TO  usefulness; 

•  Reduces  Cause  Code  1  mishaps  at  Tier  4;  and 
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•  Allows  for  TO  cost  control  separate  from  weapon  system  cost. 

AFTOMS  daily  use. can  be  made  increasingly  more  productive  by  attention  to  the  following 
issues: 

•  Practical  functionality", 

•  Database  capacity  and  quality", 

•  Performance  adequacy 

•  Reliability  and  maintainability",  and 

•  User  competency-  enhancement. 

B8. 2.2.1  Practical  Functionality 

AFTOMS  functionality  must  be  designed  and  implemented  with  operational  simplicity  as  a 
key  consideration  and  error  recovery  a  straightforward  matter.  This  is  supported  by  good 
design  and  consistent  implementation  of  simple  user  interfaces,  and  careful  allocation  of 
functions  to  the  different  classes  of  users. 

B8. 2.2.2  Database  Capacity  and  Quality 

Digital  database  capacity  sizing  must  account  for  the  number  of  TOs  in  a  TOMA's  inventory' 
(e.g.,  a  Bl-B  Bomber  adds  a  million  pages  of  new  TOs  to  some  base  of  commodity  TOs).  up 
to  30  Kbytes  of  storage  per  average  TO  page,  and  the  added  storage  required  to  support 
AFT022s,  cataloging /indexing/B+  tagging  information.  Additional  work  spaces  must  be 
provided  to  support  productive  processing  at  the  various  tiers.  The  database  must  also  be 
distributed  to  support  the  workers  while  reducing  loading  and  delays  on  communication  lines. 
The  higher  the  database  quality  in  terms  of  number  of  B+  tags  per  average  TO  page,  the 
more  storage  space  required.  Database  servers  can  be  readily  added  to  a  network  as  needed 
so  capacity  can  be  added  incrementally  and  balanced  for  improved  network  performance. 


Bo.2.2.3  Performance  Adequacy 

Access  and  processing  performance  at  the  various  tiers  are  important  to  reduce  user  frustra¬ 
tion  and  errors,  and  to  build  user  confidence  in  AFTOMS.  Performance  should  match  the 
perceived  complexity  of  the  operator  commanded  action.  For  example,  local  actions  should 
take  no  more  than  a  fewseconds  because  almost  immediate  feedback  maybe  required  forthe 
operator  to  base  the  next  action  on;  whereas,  database  searches  may  take  minutes.  Predict¬ 
ability  of  outcomes  upon  which  users  can  build  expectations  and  adapt  their  work  rhythms  is 
more  important  than  a  specific  response  time  in  any  situation.  Perhaps  for  extended  tasks,  the 
system  can  reply  with  some  indication  either  beforehand  or  during  the  operation  roughly  how 
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extended  the  operation  might  be,  and  whether  the  operation  is  progressing  satisfactorily  so  no 
further  user  action  is  needed  or  initiated  in  a  state  of  frustrated  uncertainty. 

B8. 2.2.4  Reliability  and  Maintainability 

AFTOMS  must  operate  reliable  that  is,  users  should  know  what  to  expect,  and  the  system 
should  produce  it  each  time  the  action  is  repeated  in  similar  circumstances;  breakdowns  or 
errors  should  be  fairly  rare  in  occurrence,  and  most  rare  for  frequently  invoked  actions  so  that 
their  incidence  per  human  time  (a  day,  week,  or  month)  is  no  greater  than  for  complex  or 
infrequently  performed  actions;  otherwise,  the  system  will  be  perceived  to  be  problematic 
and  unreliable;  and  recovery  from  errors  could  be  either  automatic  or  user-initiated,  but 
should  be  relatively  quick  and  straightforward  thereby  building  confidence  that  the  user  is  in 
control. 

Relying  on  effective  object-oriented  design  techniques,  adhering  to  standards,  and  using  the 
mainline  well-tested  functionality  of  production  grade  commercial  systems  should  provide  a 
highly  reliable  system;  and  good  user  interface  design  can  address  the  perceptual  issues  dis¬ 
cussed  above. 

This  approach  will  also  make  AFTOMS  more  maintainable  as  problems  within  the  integrated 
commercial  technology  products  will  be  corrected  by  the  vendors  and  the  Air  Force  need  only 
maintain  the  integrating  "glue”  software.  If  the  commercial  repair  turnaround  is  not  soon 
enough,  a  temporary  workaround  is  advised  since  making  permanent  customized  quick  fixes 
to  sophisticated  technology  products  is  difficult  and  potentially  troublesome. 

Reliability  should  also  be  extended  to  include  AFTOMS  recovery  from  contingencies.  Con¬ 
tingencies  include  abnormal  events  such  as  power  outages,  fires,  communication  inteirup- 
tions.  Electromagnetic  Pulse  (EMP)  damage  to  computers,  etc.  Impacts  on  AFTOMS  opera¬ 
tions  will  differ  depending  on  tier,  function,  and  the  contingency  scenario.  Since  TO  avail¬ 
ability  is  most  time-critical  at  Tier  4,  paper  copies  of  digital  TOs  can  be  maintained  locally 
(e.g..  at  CTODO  or  in  WAs)  for  backup.  Otherwise,  contingency  plans  should  be  developed 
and  implemented  based  on  a  set  of  contingency  threat  scenarios.  These  scenarios  should  in¬ 
clude  the  most  probable  single-event  contingencies  and  a  representative  set  of  less  probable 
multiple-event  contingencies. 

Then  an  integrated  contingency  recovery  plan  can  be  developed  (and  distributed  as  a  TO)  to 
include  both  a  common  part  which  is  applicable  to  all  contingencies  and  specific  parts  each  of 
which  is  applicable  to  a  specific  contingency  scenario.  This  plan  should  address,  but  not  be 
limited  to,  the  following  issues: 

•  Data  recovery  from  archived  sets; 

•  Workload  shifting  to  alternate  sites; 
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•  Special  equipment  (e.g.,  unir.terruptable  power  sources);  and 

•  Special  procedures  (e.g.,  rapidly  deployable  reserve  equipment). 

This  plan  should  be  balanced  and  tailored  to  reflect  the  different  cost-benefit  considerations; 
and  its  implementation  should  be  scalable  to  the  scope  of  the  AFTOMA,  each  TOMA  and 
each  CTODO.  The  configuration  tool  mentioned  in  Section  B8.2.1.1  would  incorporate  rele¬ 
vant  aspects  of  this  plan. 

B8. 2.2.5  User  Competency  Enhancement 

User  training  should  not  end  during  the  initial  installation  phase.  Once  the  user  develops  an 
experience  base  and  is  prepared  for  the  next  level  of  training,  occasional  short  training  ses¬ 
sions  are  useful  to  reinforce  good  work  habits,  and  teach  new  or  more  advanced  and  produc¬ 
tive  “power"  techniques.  This  approach  periodically  enhances  average  user  competency  to 
make  full  use  of  the  capabilities  built  into  AFTOMS  and  paid  for  by  the  Aj'r  Force. 

B8.2.3  Long-Term  Viability 

For  long-term  viability  a  system  must  support  change.  It  cannot  be  rigid  and  fragile;  difficult 
or  costly  to  change;  and  cannot  become  technologically  obsolete.  In  effect,  it  must  possess 
adequate  upgradeability.  flexibility,  and  extensibility. 

B8. 2.3.1  Upgradeability 

Application  systems  tend  to  have  long  lifecycles.  For  commercial  systems,  the  average  useful 
life  is  approximately  15  years;  whereas,  for  military  logistics  systems  such  as  AFTOMS,  the 
useful  life  must  stretch  to  20-to-30  years.  However,  the  underlying  commercial  technologies 
in  a  complex,  state-of-the-art,  integrated  system  such  as  AFTOMS  tend  to  have  average  gen¬ 
eration  durations  of  about  3  years,  with  the  more  dynamic  emerging  technologies  showing 
significant  advances  every  l-to-2  years  until  product  maturity. 

For  any  technology,  each  next  generation  of  products: 

•  Corrects  some  outstanding  problems; 

•  Offers  new  functional  capabilities,  as  well  as  capacity,  interfacing  and  perform¬ 
ance  improvements; 

•  Better  supports  relevant  government  and  industry  standards; 

•  Reduces  the  differences  in  important  user  benefits  from  the  leading  products  as 
each  provides  equivalent  (though  not  identical)  coverage;  and 

•  Generally  improves  price-performance. 

An  important  consideration  in  AFTOMS  is  tha*  technical  support  may  be  discontinued  for 
prior  generation  commercial  products  as  vendor  resources  are  shifted  gradually  to  support 
the  current  generation  products. 
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Therefore,  to  avoid  technological  obsolescence,  take  advantage  of  performance  improve¬ 
ments,  and  rely  on  vendors  for  maintenance  of  these  sophisticated  technology  products,  it  is 
essential  that  AFTOMS  be  readily  upgradeable.  For  example,  marginal  or  inadequate  re¬ 
sponse  time  can  be  easily  improved  by  a  next-generation  workstation  platform  which  (for  the 
same  or  lower  cost)  typically  will  be  3-to-5  times  faster  in  processing  speed,  and  offer  more 
internal  memory  to  reduce  the  need  for  frequent  slow  interaction  with  a  peripheral  disk  de¬ 
vice;  or,  a  future  generation  of  a  DMS  will  undoubtedly  incorporate  both  a  fully-integrated 
relational  or  object-oriented  database  and  a  fully-integrated  ODS,  both  of  which  may  be 
easier  to  use  and  higher  performing  than  those  already  in  AFTOMS.  It  may  make  sense  to 
replace  three  older  technology  products  from  different  vendors  with  a  single,  fully-inte¬ 
grated,  higher-performing  product  from  a  single  supplier. 

Upgradeability  of  AFTOMS  is  facilitated  by  using  an  open  architecture  that  maximizes  ad¬ 
herence  to  important  standards  (e.g..  POSDC,  X-Windows.  GOS1P,  ANSI  SOL  etc.)  and  se¬ 
lecting  products  that  both  support  these  standards  and  are  designed  for  hardware  indepen¬ 
dence  and  software  portability,  even  at  the  expense  of  current  performance  or  functional  ca¬ 
pability  (if  not  critical).  Current  performance  gaps  and  other  deficiencies  can  be  closed  or 
corrected  with  next  generation  products  in  an  upgradeable  configuration,  whereas  a  non- 
upgradeable  configuration  locks  in  the  current  performance  and  problems  until  a  new  sys¬ 
tem  is  developed. 

Moreover,  development  of  the  customized  user  interfaces  and  integrating  software  that 
’’glues"  the  commercial  products  together  and  makes  the  configuration  appear  as  a  single 
system  should  not  compromise  upgradeability.  Again,  standards  adherence  and  good  device¬ 
independent,  object-oriented  design  is  the  key. 

B8. 2.3.2  Flexibility  and  Extensibility 

Over  time,  new  Tier  4  technical  order  delivery  systems  such  as  IMIS,  FIDS,  and  even  more 
advanced  future  concepts  probably  will  be  integrated  with  AFTOMS;  and  AFTOMS  will 
need  to  be  integrated  with  other  CALS  systems  (e.g.  PDD)  to  support  a  more  globally  inte¬ 
grated  technical  data  environment.  Thus,  AFTOMS  needs  to  be  both  flexible  to  adapt  to  new 
unforseen  and  loosely  defined  requirements,  and  extensible  to  fully  support  them. 

For  flexibility  and  extensibility,  AFTOMS  must  have  an  architecture  and  design  infrastructure 
that  supports  new  interfaces  both  into  and  out  of  AFTOMS  and  processes  the  digital  data 
intelligently  in  between  these  interfaces.  Again,  performance  should  be  sacrificed  initially  (if 
necessary)  to  build  in  needed  flexibility  and  extensibility. 

Reliance  on  adherence  to  MIL-STD  1840  and  its  successors  for  technical  order  input  should 
make  AFTOMS  processing  independent  of  contractor's  TO  authoring  and  change  processing 
systems. 

Reliance  on  standards  (e.g.,  ANSI  SQL  POSIX,  GOSIP,  object-oriented  design,  etc.)  for  all 
processing  within  AFTOMS  will  keep  data  from  becoming  tightly  coupled  to  particular  AF- 
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TOMS  implementation  details  which  may  be  changed  sometime  in  the  future;  and  will  facili¬ 
tate  automated  data  conversion  from  one  digital  form  to  another  if  it  becomes  required.  In 
addition,  such  standardized  data  are  easier  to  access  by  future  technical  order  or  CALS  sys¬ 
tems. 

Definition  of  a  standard  AFTOMS  Tiers  3/4  interface  is  needed  to  anchor  the  distribution 
function  at  Tier  3.  Then,  new  Tier  4  ODS  systems  can  develop  their  own  unique  interfaces  to 
the  AFTOMS  standard  interface;  this  interface  layering  approach  will  isolate  technological 
developments  in  advanced  ODS  systems  from  mainline  AFTOMS  functionality,  except  for 
possible  enhancements  required  at  Tier  2  for  tagging,  verification,  and  change  processing. 

B8.3  PARTICULAR  INTEGRATION  APPROACHES 

Use  of  the  Demo  System  during  its  debug,  system  integration,  and  final  testing  stages  (prior  to 
delivery  to  the  AFTOMS  SPO)  provided  an  insight  into  some  of  the  key  issues  of  operational 
utility.  The  first  issue  concerned  how  to  realize  the  benefits  of  AFTOMS  as  soon  as  possible 
after  IOC.  User  interface  quality  plays  the  biggest  pan  in  realizing  this  objective. 

Most  computer  systems  are  judged  by  users  on  how  good  the  user  interface  is  since  that  is 
their  primary  interaction  with  the  system.  There  are  two  keys  to  a  quality  user  interface. 

•  Consistency  of  user  interface:  and 

•  Simplicity  of  user  interface. 

When  team  members  who  did  not  design  or  develop  the  user  interface  began  to  learn  how  to 
use  the  Demo  System,  they  had  little  difficulty.  The  conventions  lor  choosing  functions,  sys¬ 
tem  responses  and  acknowledgments,  graphical  aids  and  a  minimum  of  typing,  etc.  main¬ 
tained  a  level  of  consistency  within  this  system  and  made  it  similar  to  many  of  the  newer  gener¬ 
ation  systems  in  the  computing  w'orld.  This  consistency  is  the  result  of  using  standard  win¬ 
dowing  systems  'toolkits.  Simplicity  comes  from  the  use  of  a  graphics  or  picture -oriented  in¬ 
terface  which  eliminates  a  lot  of  text  input  for  the  user. 

The  second  issue  of  more  productive  day-to-day  use  can  only  be  extrapolated  from  the  lim¬ 
ited  use  by  POC  team  members.  Two  features,  fundamental  to  the  Demo  System,  which 
should  help  in  this  area  are  the  graphical  user  interface  (GUI),  which  minimizes  the  need  to 
memorize  commands,  and  the  built-in  Help  function.  In  the  GUI  design  approach,  the  user  is 
led  through  the  system  by  icons  (pictures)  and  menus  related  to  what  the  user  is  doing.  Rather 
than  typing  in  memorized  commands,  the  user  simply  chooses  valid  options  and  from  one  or 
more  layers  of  menus.  This  greatly  aids  the  casual  user. 

The  Help  function  is  built-in  and  available  while  the  user  is  working  on  the  system.  Some 
limited  experience  with  the  Help  function  showed  that  this  is  a  more  productive  way  to  assist 
users  than  hardcopy  reference  manuals  and  quick-view  reference  cards.  The  GUI,  with  mul¬ 
tiple  windows  and  direct  manipulation  features,  provides  the  mechanisms  to  build  in  suffi¬ 
cient  help  aids  to  enhance  productivity'. 
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The  third  issue  of  importance  concerns  future  enhancements.  In  the  Demo  System  debug  and 
testing  phases,  there  was  much  interaction  and  feedback  regarding  changes,  modifications, 
and  improvements  to  the  functionality  and  user  interface.  In  many  cases  this  feedback  served 
to  produce  a  better  product.  It  is  envisioned  that  once  AFTOMS  is  deployed,  there  will  be 
much  feedback  of  a  productive  nature  recommending  improvements.  The  POC’s  limited  ex¬ 
perience  of  easy  implementation  of  changes  with  these  types  of  design  and  support  tools  was 
extremely  encouraging.  Many  changes  can  take  place  without  major  redesign  by  using  this 
design  approach.  Changes  that  formerly  took  man-months  to  implement  can  be  done  in 
man-da^  or  man-weeks.  Changes  that  were  not  even  possible  because  of  time  constraints 
can  be  made.  The  Demo  System  team  was  very  encouraged  by  how  flexible  and  comprehen¬ 
sive  the  options  in  these  toolkits  are. 

B8.4  RISK  ASSESSMENT 

From  the  viewpoint  of  operational  utility  the  AFTOMS  residual  risks  include: 

•  Slow  buildup  of  the  digital  TO  database  due  to  scanning  conversion  or  DTD 
problems; 

•  Development  of  a  configuration  tool  for  planning  the  AFTOMS  support,  con¬ 
version.  and  data  loading  requirements  for  each  WS; 

•  Unavailability  of  adequate  communications  support  due  to  ULAN  A I  or  II  and 
DDN  installation  scheduling; 

•  Premature  implementation  of  Type  C  capability  before  its  unique  AFTOMS 
infrastructure  support  (in  authoring,  change  management,  verification,  and 
distribution)  is  clearly  understood  and  delineated; 

•  Difficulty  in  defining  a  standard  Tiers  3/4  interface  to  support  IMIS,  ITDS,  and 
other  future  delivery  systems;  and 

•  Capacity'  or  performance  problems  associated  with  full-scale  operations  that 
were  not  visible  in  a  limited  POC  environment. 

B8.5  RISK  ABATEMENT: 

In  general,  risk  abatement  reduces  to  three  principles: 

•  Learn  from  specific  experience  to  develop  sound  plans  and  approaches  for: 

o  Scanning  conversion; 
o  Configuration  planning: 
o  Capacity  sizing; 
o  Performance  balancing; 
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o  Degree  of  B+  enhancement  tagging;  and 
o  Type  C  integration  support. 

•  Base  AFTOMS  architecture  and  design  on  commercially  available 
technology  products  that  are  production  grade,  adhere  to  important 
standards,  integrate  well,  and  sacrifice  performance  (if  necessary)  to  maintain 
these  qualities. 

•  In  developing  the  integrating  “glue”  software  to  bring  these  commercial 
products  together,  use: 

o  Object-oriented  design  techniques; 

o  Standard  languages  (such  as  ANSI  SOL,  ANSI  C,  etc.);  and 

c  Adhere  to  standards  to  maintain  system  upgradeability,  flexibility,  ex¬ 
tensibility,  quality,  ease  of  use,  maintainability,  etc. 
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